The Atari Compendium

home *** CD-ROM | disk | FTP | other *** search

/ The Atari Compendium / The Atari Compendium (Toad Computers) (1994).iso / files / umich / telecomm / btst240l.lzh / BT_USER.DOC < prev next >

Wrap

Text File | 1989-09-04 | 168.7 KB | 3,508 lines

**** * * * ******* TM * * * * * * * * * ** * * * *** * * * *** * ** *** ** **** * ** * * * * * * * * * * * ** * * * * * * * * *** * **** * * * **** * * * * * * * * * * * * * * * * * * * * * **** * * * * * * **** **** * **** * * * * * Version 2.30 - User's Guide * September 4, 1989 *** A Freely Available FidoNet Compatible Electronic Mail Interface and Dumb Terminal Package Software Written by Vince Perriello and Bob Hartman Documentation Written by Alan D. Applegate Copyright (C) 1988, 1989 Bit Bucket Software, Co. A Delaware Corporation All Rights Reserved Terms and Conditions Contained Separately Bit Bucket Software, Co. 427-3 Amherst St., Suite 232 Nashua, NH 03063 "BinkleyTerm" and "Freely Available" are trademarks of Bit Bucket Software, Co. BinkleyTerm Version 2.30 - User's Guide - Page 2 TABLE OF CONTENTS Section 1 - General Information 4 How to Use This Manual 4 Acknowledgements 5 Kudos 6 Forward 7 Introduction 8 General Requirements 9 Memory Requirements 9 Modem Requirements 10 Section 2 - Operation as a Terminal Communications Program 11 Terminal Mode Overview 11 VT-100 Emulation 12 External Protocols 12 Section 3 - Operation as a Automated Electronic Mailer 13 Unattended Mode Overview 13 The BinkleyTerm Concept 14 How BinkleyTerm Handles Mail 14 Idea #1 14 Idea #2 15 Idea #3 15 Idea #4 15 A Sample Message, Start to Finish 17 The Concept of Cost 18 Alternative Method 18 Windowed Interface 19 Current Settings 19 Today at a Glance 19 Pending Outbound Mail 20 Recent Activity 21 Transfer Status 21 Control 21 Errorlevels and Batch Files 22 What is an Errorlevel? 23 What Errorlevels BinkleyTerm Produces 24 Making Errorlevels Work for You 26 Errorlevels, Batch Files and ExtrnMail 26 Errorlevels, Batch Files and Housekeeping 26 DOS Shell Keys 26 Using Errorlevels 27 What Now? 27 Errorlevel and Batch File Hints and Kinks 28 Environment Variable 30 Configuration File 30 BTCTL 30 Nodelist 31 FIDOUSER.LST 31 Version 5 Nodelist 32 Version 6 Nodelist 32 BinkleyTerm Version 2.30 - User's Guide - Page 3 QuickBBS Nodelist 32 TBBS Nodelist 33 Nodelist Support Information 33 Zone Support 34 Multiple Network Operation 35 Security 35 Prot 36 Known 36 Default 36 Security - Session Passwording 36 Security - Secured Inbound File Areas 37 Security - Controlling File Requests 38 Security - Response File Templates 39 BBS Interface 39 BBS Exit 39 BBS Spawn 40 BBS Batch 40 BBS Batch Method Flowchart 42 Banner 42 External Mail Programs 43 User-Selected BBS Functionality 43 File Requests 45 Update Requests 47 Request Response Files 48 Function Requests 49 $ Function Requests 49 + Function Requests 50 Function Request Notes 50 A Word About Point Networks 51 Section 4 - Problem Solving 52 BinkleyTerm Support 52 Troubleshooting 52 Baud Rate Locking Trouble 52 Outward Dial Aborting 52 False Call Collision Reports 53 FOSSIL Driver Compatibility Problems 53 BinkleyTerm Will Not Recognize Node Address 53 TBBS Difficulty - BinkleyTerm Runtime Errors 53 DOS Shells Not Working Correctly 53 Zone Support Does Not Operate Correctly 54 Date Rollover Problem 54 Glossary 54 BinkleyTerm Version 2.30 - User's Guide - Page 4 +-------------+ | +---------+ | | | Section | | BinkleyTerm User's Guide | | 1 | | GENERAL INFORMATION | +---------+ | +-------------+ HOW TO USE THIS MANUAL The documentation for BinkleyTerm is supplied in two parts. The User's Guide (named BT_USER.DOC) explains how to install BinkleyTerm. It also describes basic operational procedures. New users may find some concepts or terminology unfamiliar; a glossary is provided toward the end of the User's Guide. Concepts and terminology that may be of interest to experienced users and new users alike are covered in the Reference Guide (named BT_REF.DOC) an alphabetically arranged manual separate from the User's Guide. For inquiries, questions or comments regarding BinkleyTerm, please refer to the User's Guide section "BinkleyTerm Support." Some material in the section "How BinkleyTerm Handles Mail" is excerpted from MATRIX.DOC, and is Copyright (C) 1987 Wynn Wagner III, All Rights Reserved. Used by permission. Some material in the section "Control" was written by Ron McKenzie, and is Copyright (C) 1989 Ron McKenzie, All Rights Reserved. Used by permission. BinkleyTerm Version 2.30 - User's Guide - Page 5 ACKNOWLEDGEMENTS The following names are either trademarks, registered trademarks, and/or the efforts of the person and/or company named: Fido, FidoNet - Tom Jennings, Fido Software MS-DOS, Microsoft C - Microsoft Corporation IBM, PC-DOS - International Business Machines Corporation Opus-CBCS, ZedZap, YooHoo, WaZOO, OpusNode - Wynn Wagner III ARC, SEAdog, SEAlink, XlatList, ARCmail, GroupMail - Thom Henderson, System Enhancement Associates, Inc. VT-100, DEC, DEC Rainbow, VAX, VMS - Digital Equipment Corporation FANSI-CONSOLE - Hersey Micro Consulting Hayes - Hayes Microcomputer Products Corporation Zmodem - Chuck Forsberg, Omen Technologies, Inc. ConfMail, ParseLst, oMMM, Opus!Comm - Bob Hartman, Spark Software, Inc. oMMM - BS Software, Marshall Presnell, Jim Nutt msged - Jim Nutt XlaxNode - Scott Samet Heath/Zenith - Heath/Zenith Electronics, Inc. Sanyo - Sanyo Electric Co. (Japan) Ltd. DoubleDOS - SoftLogic Solutions, Inc. DESQview - Quarterdeck Office Systems, Inc. Telix - Colin Sampaleanu, Exis Inc. Sirius - Bob Klahn, Micro Solutions OOPS - Tom Kashuba AMAX - Alan Applegate Dutchie - Henk Wevers PC Pursuit - GTE/Telenet EchoMail - Jeff Rush ProComm - Datastorm Technologies, Inc. Qmodem - The Forbin Project TBBS - Phil Becker, eSoft, Inc. QuickBBS - Adam Hudson X00 - Ray Gwinn, RENEX Corporation DECCOMM - Vince Perriello, VEP Software Atari, ST - Atari, Inc. Commodore, Amiga - Commodore International USRobotics, HST - USRobotics, Inc. RBBS-PC - Capital PC Users Group, Thomas J. Mack FrontDoor - Joaquim Homrighausen D'Bridge - Chris Irwin Every effort has been made to identify and give credit for trademarks mentioned in this documentation. Any failure to mention a particular trademark in the above list that may be found in the text, or failure to give proper credit for a particular trademark, constitutes merely an oversight and should not be construed as intentional, or in any way a claim of rights to the trademark. PLEASE NOTE! Throughout this documentation, the mention of any BinkleyTerm Version 2.30 - User's Guide - Page 6 particular software package or system should not be construed as an endorsement of any kind on the part of the authors. KUDOS A number of people have been involved in the creation, development and testing of this program, or have contributed to it in one way or another. Tom Jennings, of course, gets credit for creating the beast that brought us all together and defining the basic method of mail transfer that we still use. Wynn Wagner gets our thanks for releasing source code for his file transfer routines and sending some of his WaZOO source code as well for inclusion. Thom Henderson gets a humble tip of the hat for SEAdog, the prototypical mail-only front-end which was the basis for our front-end design, and for SEAlink, his extension of Xmodem/Telink which doubled the speed of network mail transfers overnight. Chuck Forsberg of Omen Technologies gets our thanks for developing and implementing the original Zmodem protocol. Then there are the guys who have put to the test everything the authors thought would be worthwhile, the BinkleyTerm Beta Test Team, members both past and present. Without you, who knows what we'd have wound up with. BinkleyTerm Version 2.30 - User's Guide - Page 7 FORWARD There is no question that BinkleyTerm is an extremely powerful communications tool. We also make no secret of the fact that BinkleyTerm is an extremely complex communications tool. A set of documentation the size of an unabridged dictionary (about 150mm thick or so) would still not address every possible use of BinkleyTerm in every possible environment. BinkleyTerm can run on a number of personal computer platforms - a total of several thousand brands and models. Hundreds of different modems can be used. It works with several operating environments such as DESQview and DoubleDOS. In addition, BinkleyTerm is designed with an open architecture, so it can be used with several BBS packages, nodelist processors, mail processors, editors, and so on. BinkleyTerm "ports" have been made for entirely different platforms such as the Atari ST, Commodore Amiga and VAX/VMS based systems. You begin to get the scope of what's involved. This documentation attempts to cover fairly broad generalities in configuring and operating BinkleyTerm. It cannot and will not cover all possibilities or circumstances. Hopefully it will serve as a starting point - a ground level from which you may grow and expand. Further, this documentation describes only the version of BinkleyTerm provided by the original authors - that which runs in the PC-DOS/MS-DOS environment. Most of the enjoyment of the electronic mail hobby comes from trying new things - tweaking the system. Although BinkleyTerm is a dependable, powerful program that is not especially difficult to get going, it does provide ample opportunity to experiment and have fun. Still, if you're looking for something that will meld itself into your computer in just a few minutes and work without modification forever more, BinkleyTerm should probably not be your first choice. In exchange for a little complexity, we give you power and an incredible amount of configurability and compatibility. If you become frustrated with BinkleyTerm, call on others in your area who have configured it for an environment similar to yours. We estimate that several thousand people around the world are BinkleyTerm users, and someone close to you in your network no doubt runs BinkleyTerm. With an architecture as open as that of BinkleyTerm, your best source of information is someone who has the benefit of time and experience configuring it. Of course, you will eventually become an expert yourself! Enjoy it, and delight in the wonder of technology. Alan D. Applegate, Vice-President, Bit Bucket Software, Co. BinkleyTerm Version 2.30 - User's Guide - Page 8 INTRODUCTION BinkleyTerm is an advanced, state-of-the-art telecommunications tool. It is primarily designed for the semi-automated sending and receiving of electronic mail and files within FidoNet- compatible electronic mail networks. When used as a mailer, BinkleyTerm is designed to communicate with any FidoNet-compatible mail interface or BBS package. The program uses standard FidoNet protocol, as well as certain modified protocols supported by programs such as SEAdog and Opus- CBCS. It also offers easy-to-use event scheduling, single keystroke spawning to other programs (DOS shell), excellent support for high speed modems, advanced session recovery, inbound call collision detection, and much more. When used as a dumb terminal, BinkleyTerm offers a rich selection of file transfer protocols for exchanging files with a host system. The program also offers keyboard macros, optional VT-100 emulation, echoing of the on-line session to a flat text file or printer, support for baud rates of 300 to 38,400 and more. BinkleyTerm can be used as a dumb terminal program exclusively, as a mail interface for a Point system, or as a front end mail interface for an electronic bulletin board system (BBS). Mail interface and dumb terminal operations can be switched in and out with a minimum of effort providing dual functionality. BinkleyTerm is one of several software packages to utilize the FOSSIL standard communications driver. This standard allows for consistent console (keyboard and screen) and communications port I/O operations. By using a FOSSIL driver, BinkleyTerm is capable of running on practically any MS-DOS/PC-DOS capable machine, even those that are not 100% IBM hardware compatible. BinkleyTerm endeavors to provide you with the widest possible variety of advanced features, combined with solid and efficient operation in a wide range of hardware environments. BinkleyTerm Version 2.30 - User's Guide - Page 9 GENERAL REQUIREMENTS - A personal computer running MS-DOS or PC-DOS, with at least 256k of available RAM. - MS-DOS or PC-DOS, Version 2.10 or greater, Version 3.20 or higher preferred. - An auto-dial, auto-answer modem; should be mostly "Hayes compatible." See "Modem Requirements" below. - A FOSSIL driver designed for your particular hardware. - One 360k floppy disk drive (Terminal Mode). - At least two 360k floppy disk drives, more space and/or hard disk recommended (Unattended Mode). - Basic knowledge of computer-based telecommunications, without which you would have no need for BinkleyTerm. Please note that when using BinkleyTerm as a front-end mailer for a BBS system, a hard disk is required. The more space you have for such an operation, the better off you'll be. You will also need various utilities and adjunct programs, which vary with your application. MEMORY REQUIREMENTS BinkleyTerm requires approximately 185k of RAM in any operational mode with the non-overlay version (BTBIG.EXE) and somewhat less for overlay version (BT.EXE). When used for Unattended Mode, additional memory sufficient to hold the nodelist index file (usually NODELIST.IDX) will also be required. Keep in mind that a small amount of overhead will also be required to accommodate a FOSSIL driver, as well as a VFOSSIL if one is used. At least a 512k system is recommended when using DOS shells, or when BinkleyTerm is used in a multi-tasking environment. BinkleyTerm should, however, be completely functional even on a system with only 256k of RAM. BinkleyTerm is not currently capable of taking direct advantage of extended (AT style) or expanded (EEMS, EMS 4.0) memory, and having such memory installed will not be of direct benefit to BinkleyTerm. Some multi-taskers, such as DESQview, are able to take advantage of such memory to BinkleyTerm's ultimate benefit. Please note, however, that when using the 'SwapDir' configuration file statement, a RAM disk with at 150k of available space is highly recommended for efficient operation. Typically RAM disks can be placed in extended or expanded memory. Refer to the Reference Guide section "Configuration File" for details on the 'SwapDir' statement and its use. BinkleyTerm Version 2.30 - User's Guide - Page 10 When used as a front end mailer for a BBS system, it is HIGHLY RECOMMENDED that the 'BBS Batch' method of accessing your BBS be implemented for the most efficient use of memory. Please refer to the applicable sections of the documentation for further information. MODEM REQUIREMENTS A modem that is generally "Hayes compatible" is required for BinkleyTerm operation. Such modems are typically referred to as "smart" modems. Most popular, late model modems you're apt to own meet this requirement. Since you configure the various modem command strings, the modem does not need to be 100% Hayes "AT" command set compatible, but it does need to use the "AT" style of issuing modem commands. Most smart modems are capable of returning VERBAL (full words) or NUMERIC (numbers only) response codes; the modem must be configured in such a way as to use the VERBAL codes ONLY. BinkleyTerm can be operative if the modem supports just one modem response string - CONNECT. (See below for qualifications required of the CONNECT string.) BinkleyTerm has been programmed to handle and respond appropriately to the following modem response strings: NO ANSWER, BUSY, RING, VOICE, NO DIAL TONE, NO DIALTONE, ERROR, NO CARRIER, DIAL TONE and DIALING. The following response strings are recognized, but are ignored: RRING, RINGING and RING RESPONSE. With the exception of the CONNECT response, any other data provided by the modem after a given response string is ignored. For example, "NO CARRIER DETECTED" would be handled in the same manner as a "NO CARRIER" response. Since BinkleyTerm uses the CONNECT string to determine connection baud rates, the modem should be capable of sending such strings. Generally, CONNECT is a default, and indicates a 300 baud connection. Other possible connections should be CONNECT 1200 for a 1200 baud connection, CONNECT 2400 for a 2400 baud connection, and so on, up to the maximum supported speed. Note also that BinkleyTerm recognizes the response CONNECT 1275 for split-speed modems. If you are experiencing modem difficulties, try one or all of the following configuration file statements: 'SlowModem', 'SameRing' and/or 'NoCollide'. Additionally, not all modems are capable of using the 'Answer' statement and its related modem configuration. Explanations of all these statements can be found in the Reference Guide section, "Configuration File." BinkleyTerm Version 2.30 - User's Guide - Page 11 +-------------+ | +---------+ | | | Section | | BinkleyTerm User's Guide | | 2 | | OPERATION AS A TERMINAL COMMUNICATIONS PROGRAM | +---------+ | +-------------+ TERMINAL MODE OVERVIEW This section describes the installation and operation of BinkleyTerm in the Terminal Mode. BinkleyTerm's Terminal Mode offers functionality similar to that provided by programs such as Telix, ProComm or Qmodem. You can use your computer and modem to call out to on-line services and electronic bulletin board systems (BBS). BinkleyTerm offers a full selection of file transfer protocols for use in exchanging files with remote systems. Also offered is optional VT-100 terminal emulation, an open architecture for adding additional file transfer protocols, support for high speed modems up to 38,400 baud, session logging to a flat file or printer, and more. BinkleyTerm also features Zmodem Auto-Downloads. Once the transfer begins at the remote host, BinkleyTerm will detect the unique Zmodem start-of-transfer signal, and will immediately go into Zmodem download mode. If for some reason the Auto-Download does not occur, a Zmodem download can always be initiated manually. To install and operate BinkleyTerm for use exclusively in Terminal Mode, follow these steps. - Prepare disk media. Create a sub-directory on your hard disk, or format a single diskette. - Move the software to the newly prepared media. - With a standard text editor, or with DOS' EDLIN command, edit the sample configuration file, BINKLEY.CFG, included in the distribution archive or diskette. The parameters needed are outlined in the file itself on comment lines, or you may refer to the Reference Guide for more information. - Obtain and properly install a FOSSIL driver in accordance with the directions included with your driver. (Refer to the Glossary for more information on FOSSIL drivers.) - Invoke BinkleyTerm (enter 'BT' on the command line). - Press Alt-F10 for a brief help screen. The various keystrokes available in Terminal Mode are covered in BinkleyTerm Version 2.30 - User's Guide - Page 12 detail in the Reference Guide. VT-100 EMULATION VT-100 terminal emulation is provided optionally by BinkleyTerm. Outward keystrokes are always active with the VT-100 keypad mapping (as shown in the Reference Guide). However, incoming screen control codes require ANSI X3.64 support, such as that provided in firmware on a DEC Rainbow computer. For users of IBM PC computers and compatibles, external ANSI support is required, as provided by FANSI-CONSOLE, a separately available utility. Load FANSI-CONSOLE in accordance with its directions prior to running BinkleyTerm for full VT-100 terminal emulation. EXTERNAL PROTOCOLS BinkleyTerm provides a rich selection of file transfer protocols, hard coded for ease of use and efficient operation. On occasion however, other protocols may also be desired. BinkleyTerm supports special external file transfer programs that conform to the standard used by Opus-CBCS. External file transfer protocols MUST identify themselves as being compatible with Opus-CBCS in order to work with BinkleyTerm. Such protocols are often available from Opus-CBCS systems. Protocols currently available include WXmodem, Kermit and others. To use such an external protocol, add a 'Protocol' statement to your configuration file along with the required path information, as illustrated in the Reference Guide section "Configuration File." Some of the Opus-CBCS compatible protocols are specially designed and optimized for BBS use, and may not be operable in BinkleyTerm's Terminal Mode. Check the individual package for information, or test the performance of the package on your own. "True" external protocols, those that are designed to be accessed by any communications program via a DOS shell, can also be used with BinkleyTerm. BinkleyTerm provides a DOS shell command that can be invoked during a communications session. An external protocol of this type can then be executed from the DOS command line, or from a batch file, depending on your situation. External protocols such as Jmodem and BiModem can be accessed in this manner. BinkleyTerm Version 2.30 - User's Guide - Page 13 +-------------+ | +---------+ | | | Section | | BinkleyTerm User's Guide | | 3 | | OPERATION AS AN AUTOMATED ELECTRONIC MAILER | +---------+ | +-------------+ UNATTENDED MODE OVERVIEW This section describes the installation and use of BinkleyTerm in Unattended Mode. This mode is used when BinkleyTerm is to function as a front-end mail interface, whether in a BBS or "Point" environment. The Glossary provides information on BBS and Point systems. BinkleyTerm, in this operational mode, provides functionality similar to that provided by programs such as SEAdog, Dutchie, FrontDoor, D'Bridge and other FidoNet compatible mailers. BinkleyTerm answers the telephone, and exchanges mail with other compatible mail interface packages, or in the case of a human caller, passes control of the connection to a BBS system. Due to the complexity and widely varying combinations of hardware and software, only a generalized, broad explanation of the installation procedure can be given. - Prepare your disk media. Normally, this would involve selecting and/or creating a hard disk sub-directory. - Move BinkleyTerm and the distribution files to this new directory. - Using any standard text editor, make the necessary changes to the configuration file included with the distribution archive or package. Refer to the Reference Manual section "Configuration File" for more information. - Run the BTCTL program included in the distribution package. - Obtain and install a FOSSIL driver. Refer to the Glossary for more information. - Obtain the necessary utilities and programs for packing and unpacking mail. Install them in accordance with the instructions included with each package. - If you're a fully qualified FidoNet node (not a Point), obtain a current nodelist. Process it into usable form. - Make the appropriate changes to an existing batch file used to start your BBS. If the installation is completely new, or if your BBS does not use a batch file, create one. Refer to the section "Control" for more information. BinkleyTerm Version 2.30 - User's Guide - Page 14 - Start your system. Test a remote call if possible. - Alt-F10 displays a brief help file of commands available in Unattended Mode. THE BINKLEYTERM CONCEPT It is important to remember that BinkleyTerm is a mailer program with a completely open architecture. As such, BinkleyTerm can be operated with a tremendous variety of BBS systems, mail packing and unpacking programs, and accessories. BinkleyTerm will answer the telephone and respond to another mail program. Mail will be placed in an incoming files area. If the caller is human, control is passed entirely to the BBS program, if one is installed. It is the responsibility of third-party software to unpack the mail received, and add it to your message base. On the outward side, BinkleyTerm uses an outbound holding area to hold outward mail. It is the responsibility of third-party packing software to pack new messages into the required format, and place them in the outbound area. BinkleyTerm neither packs nor unpacks mail. Allowing this functionality to be provided by other software allows BinkleyTerm to be compatible with practically any BBS software, regardless of message base structure. For mail handling, you might use programs such as ConfMail and oMMM to process mail, along with programs such as Sirius or msged to read and enter messages, or allow your users to do so in a BBS installation such as Opus-CBCS or Fido. Some BBS packages, such as TBBS and QuickBBS come complete with their own proprietary packing and unpacking software. Finding the utilities and programs needed to work with your system is your responsibility. HOW BINKLEYTERM HANDLES MAIL Sending outbound mail with BinkleyTerm is fairly simple. The concept of mail handling with BinkleyTerm is the same concept that Opus-CBCS uses. If you're already familiar with Opus, then BinkleyTerm will fall into place easily. If you are a complete neophyte, this section is intended to give you an understanding of the concept. Idea #1 Mail events are less important than they are with other mailing methods and systems. With BinkleyTerm's events, you paint with a wide brush telling the system what to do with 'classes' of remote systems. BinkleyTerm Version 2.30 - User's Guide - Page 15 When systems handled mail only at specific times, routing and times were of great importance. Because more and more systems can process mail at any time, the idea of a schedule becomes less important. The item of prime importance with BinkleyTerm is COST. We are going to try and relieve you of the tedious details of scheduling, and concentrate on doing things for the least cost. More on this later. Idea #2 Another new idea deals with the way that packets are created. If you have used other mailer systems, you're probably used to seeing packets generated several times. With some programs, packets are built every time a mail schedule starts. As a result, one message may be put into a packet several times. With BinkleyTerm, packets are built once by an external mail packing program. Most often, this is a program called oMMM. They may be remarked and rerouted once they're built, but they are physically built only once, and placed in a special sub- directory called the outbound holding area. NOTE: oMMM stands for Opus Matrix Message Masher, and was originally designed for use with the Opus-CBCS system as its packer. BinkleyTerm is able to use oMMM because it chose to implement the holding area in a compatible (although not identical) way. oMMM may not have to be used at all; in some cases, the mail packing program for your particular environment may handle oMMM-like functions internally. Idea #3 BinkleyTerm uses 'Continuous Mail.' If you are already using a program that supports 'Crash Mail' then you understand a little of what Continuous Mail does. Continuous Mail differs from Crash Mail in a couple of areas. In other mailer systems, you would mark a message as 'Crash' meaning that you wanted this message to go out NOW. These mailer programs would shut down human caller access to the BBS and try like heck to get the message through. BinkleyTerm uses Continuous Mail, meaning that this is a message going to a system that can accept mail at any time of day. BinkleyTerm makes no frantic attempts to dial out, rather it will try and deliver the message between callers. Idea #4 The driving forces of outbound traffic are file names! You'll have a special sub-directory set aside just for packets, compressed mail packets and other network files. This sub- BinkleyTerm Version 2.30 - User's Guide - Page 16 directory belongs to BinkleyTerm, which will maintain the directory for you. It's a good idea not to play with this area unless you know exactly what you're doing. Note also that when zoned operation is active (BinkleyTerm default) there are separate outbound areas for each zone. The default outbound area (for your zone) and one additional area for each other zone you deal with. The names of these additional areas are simply the outbound area name, with a three-digit extension that is the zone number in hexadecimal with leading zeroes. See "Zone Support" for information. The file names of the packets tell BinkleyTerm how to treat the different packets. Here's a typical packet name: 00680024.OUT That says that the packet is for 0068/0024 (in hexadecimal) or 104/36 in more familiar terms. The ".OUT" means it is a Normal packet. Other packet extensions include: .HUT . . . Hold this packet for pickup by the remote system. .CUT . . . The other system can receive Continuous Mail. .DUT . . . Direct, meaning the other system can NOT receive Continuous Mail. One nice thing is that you can manually change the file extension if you need to, or you can use fancy utilities such as AMAX to do this sort of thing for you on your command. For the remainder of this section, we'll assume that you'll be using oMMM as your mail packer. As mentioned previously, you may be using another program that has oMMM-like functionality; it depends on your environment. The oMMM program knows about these extensions and creates them based on information you put into the oMMM control file. You'll have statements like this: NormHold 124/102 Any messages you enter to 124/102 would be turned into a .HUT packet file, placed into the outbound area, and BinkleyTerm would hold that packet for 124/102 to call and pick it up. Files are also sent through FidoNet compatible networks. oMMM builds and maintains a file that tells BinkleyTerm what files to send (or hold) for whom. A typical 'file attach' file might be named: 00680024.FLO BinkleyTerm Version 2.30 - User's Guide - Page 17 This would designate a that there is a file waiting to be sent to 0068/0024 (in hexadecimal) or 104/36 in more familiar terms. The ".FLO" says it is a Normal file attach. File attach files are also called 'flow files' - named after the .FLO file extension. Other flow file extensions are: .HLO . . . Hold these files for pickup by the remote system. .CLO . . . The other system can receive Continuous Mail. .DLO . . . Direct, meaning the other system can NOT receive Continuous Mail. A flow file is just a text file. It contains a list of files that are to be sent to another system: #c:\binkley\outbound\0000fc9c.mo1 ^c:\myfiles\wizzle.doc c:\pascal\notes.doc The '#' prior to a flow file entry says to truncate the file to zero-length after successfully sending the file to the remote system. This is normally only employed when sending compressed mail (archived mail) to the remote. The '^' prior to a flow file entry says to delete the file after sending. The oMMM program will put messages into archives for you. Details on how this is done can be found in the oMMM documentation. The point is that oMMM combines the functionality of "generating packets" with that of programs like ARCmail. A Sample Message, Start to Finish So here's a practical example. Say I enter a message to Rod Lamping at 104/610. I mark the message as KILL/SENT when I enter it. I also enter the message designating a file to attach to Rod, named C:\FILE\REQ\FOOBAR.ARC. I then enter a message in an EchoMail conference. My conference host is Phil Kaiser at 104/904, for whom I hold my mail for pickup. Among other things, I have two lines in my oMMM control file: NormCM 104/610 OneHold 104/904 'NormCM' tells oMMM to mark the message as Continuous Mail (since Rod runs a mailer 24 hours a day). 'OneHold' tells oMMM to archive the mail to 104/904, and mark it Hold-for-Pickup. Refer to the oMMM documentation for the full set of available oMMM control file statements. First, my EchoMail utilities are run to turn EchoMail messages into Normal packets, and place them in the outbound area for BinkleyTerm Version 2.30 - User's Guide - Page 18 processing by oMMM. Next, I execute oMMM. It first scans the NetMail message area (where I entered my message to Rod) and turns new messages there into Normal packets, and if there are files attached, it creates Normal flow files. oMMM's second step is to use its control file, and apply the statements in the file against the mail in the outbound area that is marked as Normal. Since I have Rod's board listed as NormCM, oMMM renames the file extension of the Normal packet and flow file for Rod to .CUT and .CLO respectively, for Continuous Mail. Since I have Phil's board listed as OneHold, first oMMM archives the packets to Phil, then creates a flow file with a file extension of .HLO for Hold- for-Pickup. I would then have the following in my outbound area: 00680262.CUT Message to Rod 00680262.CLO Flow File to Rod 00680388.HLO Flow File to Phil 0000FC9C.MO1 Archived Message to Phil For more information on how oMMM works, refer to the oMMM documentation. The Concept of Cost As mentioned earlier, one of the prime considerations with BinkleyTerm is sending mail for the least cost. Cost is, of course, determined by the nodelist entry. With a properly compiled nodelist, local FidoNet nodes have '0' in the cost field for their nodelist entry (assuming local calls are free of charge). Other entries have cost fields that realistically reflect the actual cost of sending mail to a particular node. In most areas, it is cheapest to send toll calls during nighttime house. Therefore, BinkleyTerm is normally set-up to send such mail only during nighttime hours. The 'L' flag used when scheduling events designates 'local only.' As already mentioned, nodes with a '0' cost field are assumed to be local. When the flag is applied to an event, only local calls are made. The 'L' flag should be used whenever it costs the most money to make toll calls, and removed for events during which toll calls are cheapest. More about this is in the Reference Manual section, "Scheduling Events." Alternative Method Randy Bush of 1:105/6 has assembled a package called MOOO which allows the Dutchie mail packer to be used with BinkleyTerm. This will allow routing commands familiar to grizzled FidoNet veterans to be used with BinkleyTerm. BinkleyTerm Version 2.30 - User's Guide - Page 19 WINDOWED INTERFACE BinkleyTerm features a windowed user interface. The windowed interface provides "at-a-glance" convenience for watching mail sessions in progress, as well as determining what activity has taken place with the system recently. If a Video FOSSIL (VFOSSIL) is installed, the windowing operations can take place much faster than they would without one. It is recommended that a VFOSSIL be used with BinkleyTerm. Some more recent VFOSSIL implementations may also allow BinkleyTerm to be used on EGA and VGA systems in extended text modes of 132 columns by 43 lines. The mode switching must be performed by the utility software that accompanied your video card prior to invoking BinkleyTerm. There are five information windows displayed on-screen. Current Settings This window contains various information about your system, including the current date and time, current event, port and current baud rate, status and multi-tasker type, if any. The current event line features a number, and a list of event flags. The number corresponds to which entry in the BinkleyTerm configuration file contains the line that covers the current event. The first 'Event' statement in the configuration file would be event 1, the second would be event 2, and so on. The flags are letters that are a subset of those used with event scheduling. Here is a list of letters that may be found in this window: C Continuous Mail Only Event L Local Only Event N Do Not Accept Inbound File Requests R Receive Only Event B BBS Use Allowed D Dynamic Event K Do Not Send to #CM Nodes Note that not all event flags will be displayed in the window. For complete details and use information, see "Scheduling Events" in the Reference Guide. Today at a Glance This window contains several lines of information regarding the activity on your system since midnight. Note that the totals given apply only to calls handled by BinkleyTerm's Unattended (mailer) Mode, and do not include Terminal Mode totals. The first line, "BBS/Mail," lists how many bbs calls and mail BinkleyTerm Version 2.30 - User's Guide - Page 20 calls have come in, separated by a slash. For example, 2/15 would indicate 2 BBS calls and 15 mail calls since midnight. The second line, "Calls Out," lists the number of dial attempts that have been made by your system, successful or otherwise. The third line, "Good/Cost," shows how many successful outward connects have been made and the cumulative cost of all the successful calls, separated by a slash. For example, 3/100 would indicate that 3 successful outbound calls have been placed, and that together, they cost 100 units (in the United States, units are cents, which would mean that the cost was 100 cents or $1.00). The cost is calculated based on the cost shown in your compiled nodelist files; the cost shown there is assumed to be a per-minute value in calculating a per-call cost. The fourth line, "Files I/O," shows how many files (packets, compressed mail or other incoming files) have been received and sent, separated by a slash. For example, 12/3 would indicate that 12 files have been received, and 3 have been sent. Finally, the fifth line indicates the type of last call. If the last call was incoming, the display will indicate whether the call was a BBS call, external mail call, or the node address will be displayed if it was a mail call. If the last successful call was outgoing, the node address will be displayed. Pending Outbound Mail This window displays a list of systems for whom mail is pending, along with related information. The window can be scrolled using PgUp, PgDn, Home, End, Up-Arrow and Down-Arrow keys. The top line of the window lists the node that is being called, or was just called. The second line lists the node that will be called next. Various information about the mail for the various nodes is also displayed. The columns are marked by a single letter. The column letters and their meaning are: C Continuous Mail H Hold-for-Pickup Mail D Direct Mail N Normal Mail R File and/or Update Request S Status The symbol shown under the C, H, D, N and R columns is: * Mail of This Type Pending BinkleyTerm Version 2.30 - User's Guide - Page 21 The symbols shown under the S column are: x Too Many Bad Connects (Undialable) # Already Called, But Mail Still Pending - Cannot Call During This Event ! Node Not Found in Nodelist When BinkleyTerm is making an outbound call, the node you are calling is highlighted in the Pending Outbound Mail window. This allows you to know which node has been called, even after the pertinent information has scrolled out of the Recent Activity window (described below). This feature can also be helpful in determining whether an active mail session was initiated by you, or was started by an incoming call. The outbound area is re-scanned for new additions under the following circumstances: - After a keyboard shell has been invoked - After 'AfterMail' is run (if designated) - After 'Packer' is run (if designated) - After message editor (Alt-E) has been run - After 10 minutes of no activity Note the 'AfterMail', 'Packer' and 'Reader' (message editor) are designated in the configuration file. Refer to the Reference Guide section "Configuration File" for additional information. Recent Activity This window is similar to the main section of previous BinkleyTerm displays, in that it gives various information about what the system is currently doing, or has just done. This includes identification of the remote system, the type of connection, what files were transferred, etc. Any feedback available about the current or recent activity of the system is shown in this window. Transfer Status This window gives particulars about current file transfers that may be taking place if a connection is active. For WaZOO/ZedZap connections, this includes filename and the number of bytes transferred; for other connections, the number of blocks transferred may be given. CONTROL In Unattended Mode, BinkleyTerm is normally used with batch files that control system operation. You'll have a batch file used to invoke BinkleyTerm and invoke system utilities such mail processors. BinkleyTerm Version 2.30 - User's Guide - Page 22 Since BinkleyTerm can be used in such a wide variety of situations, there is not a particular "correct" or "incorrect" way to configure BinkleyTerm. The remainder of this section explains some of the operational theory and methods behind batch processing as it applies to BinkleyTerm. If you are adding BinkleyTerm to an existing FidoNet compatible BBS system, chances are excellent that you are already familiar with batch files and the various tricks that they must typically perform in a FidoNet environment. If advanced batch processing is beyond your scope, it is highly recommended that you review your DOS manual, or the numerous third-party DOS usage guides for information to get you started. One of the fundamentals of using batch files with BinkleyTerm is the concept of the 'errorlevel.' This DOS environment variable is set to a given value when a program completes execution. A batch file can detect and act upon the value, branching to various parts of the batch file. This section provides many good tips and ideas for errorlevel and batch file processing. Also consult your DOS manual for additional information. A practical application might be after BinkleyTerm receives mail. BinkleyTerm would exit to the batch file, setting the errorlevel to a predetermined value. The batch file detects the value, and branches to a section in the batch file where mail unpacking programs are invoked. The batch file would then be restarted, invoking BinkleyTerm to again wait for or send mail. NOTE: The remainder of the "Control" section was written by Ron McKenzie of 1:104/45.1. My gracious thanks to him for the insights presented here, and for the time he contributed to its composition. This section was sorely needed (and requested) by many BinkleyTerm users. - Alan D. Applegate Errorlevels and Batch Files Errorlevels present a difficult hurdle to the new user of BinkleyTerm, especially those with no experience operating a BBS or a Point. In addition, BinkleyTerm's great flexibility confuses some Sysops. Few things are "fixed" or "cast in concrete." This section attempts to draw together pertinent information from many sources relating to errorlevels and their use in crafting a batch file to operate a BBS or a Point. Also presented are some accumulated bits of wisdom gathered by the author in the course of creating his own Point. This section looks at what errorlevels are, which errorlevels are returned by BinkleyTerm, distinguishes between those errorlevel values set by BinkleyTerm and by the user, shows how you use BinkleyTerm Version 2.30 - User's Guide - Page 23 errorlevels in your batch file and, finally, offers some hints and shortcuts. What is an "Errorlevel?" An errorlevel is a numeric value which a program may "return" when it terminates. The name is misleading because the value returned is really an exit code, rather than an indication of an error per se. It distinguishes different types of normal exits, in addition to denoting an abnormal condition on exit. The software's creator (or, in some instances, the program's user) sets the value(s). Errorlevels permit the user to craft a batch (.BAT) file, using DOS batch commands such as IF and GOTO, to logically organize the BBS or Point operating process. Automagically, this batch file determines which tasks need be performed and in what order. It branches between tasks based on the exit code generated by each program and on the program logic created by the Sysop. For example, an editor might return the following: Exit Code Condition ---- ---------------------------- 3 EchoMail and NetMail Created 2 EchoMail Only Created 1 NetMail Only Created 0 No Mail Created For another example, the ConfMail mail processing program returns the following errorlevels in the Import mode: Exit Code Condition ---- ---------------------------- 2 Severe Error in Processing 1 Messages Were Imported 0 No Messages Imported Branching or jumping within the batch files is facilitated with the use of labels. A label is used to identify a particular block within the batch file. For example, you might choose to label a portion of your batch file "nodelist" because that particular section of the file handles nodelist processing. Labels are designated with a colon, followed by the label name. You may wish to identify the top of the file with a label to make re-starting the batch file as easy as using a GOTO statement. Here is a short example of the use of labels: :start myprog -p1 BinkleyTerm Version 2.30 - User's Guide - Page 24 if errorlevel 2 goto process if errorlevel 1 goto start if errorlevel 0 goto end :process proc -c -d1 if errorlevel 1 goto start if errorlevel 0 goto end :end Note that the top of the file is identified by a label named "start" and that other sections are labeled as well. The batch file starts out by invoking a program called MYPROG. Once MYPROG exits, the errorlevel values determine where in the file that control will be passed. One errorlevel references another label that in turn will cause a program named PROC to be run. Another branch goes back to the top of the file, and yet another goes to the end of the file. The PROC program also gives errorlevels that are processed by the batch file. Errorlevels and associated batch processing commands permit tailoring the batch file and bypassing of unnecessary processing steps, saving substantial amounts of time, which, in turn, translates into more time for user-access and other processes. (There is NEVER too much time.) What Errorlevels BinkleyTerm Produces BinkleyTerm returns errorlevels in four general cases: Sysop-Initiated Fx keys, Escape and Alt-X Sysop-Defined E1=, E2= and E3= exits used with event scheduling, and external mail program exits Caller-Initiated A non-mail call returns the baud rate code System-Generated BinkleyTerm cannot find itself in the nodelist What errorlevels (exit codes) does BinkleyTerm return? Many values are "hard coded" in BinkleyTerm or are provided in the sample files included in the distribution package. However, only some of the values have "fixed" definitions. BinkleyTerm Version 2.30 - User's Guide - Page 25 Error- Level Means Caused By --------- -------------- ---------------------------------- 1 Exit Alt-X Keypress 3 300 bps Call Non-Mail Call at 300 Baud 10 E1= Exit ** F1 Keypress * 12 1200 bps Call Non-Mail Call at 1200 Baud 20 E2= Exit ** F2 Keypress * 24 2400 bps Call Non-Mail Call at 2400 Baud 30 E3= Exit ** F3 Keypress * 40 ** F4 Keypress 48 4800 bps Call Non-Mail Call at 4800 Baud 50 ** F5 Keypress 60 ** F6 Keypress 70 ** F7 Keypress 80 ** F8 Keypress 90 ** F9 Keypress 96 9600 bps Call Non-Mail Call at 9600 Baud 99 ExtrnMail External Mail String Received ***** 100 ** F10 Keypress 128 38400 bps Call Non-Mail Call at 38,400 Baud **** 192 19200 bps Call Non-Mail Call at 19,200 Baud 254 Error Address Not Found in Nodelist *** 255 Error Microsoft C Produced Error * As shipped; the sample BINKLEY.EVT event file included in the distribution package uses errorlevels 10, 20 and 30 for E1=, E2= and E3= exits respectively. Thus pressing F1, F2 or F3 has the same effect as BinkleyTerm making an E1=, E2= or E3= exit. Exits are defined as: E1= Beginning of Event E2= Mail Received E3= Compressed Mail Received ** All F-key exits have user-defined functionality. *** BinkleyTerm will exit with errorlevel 254 when it cannot find its own address in the nodelist. Other conditions checked are: - Non-Zero Zone Number Designated - Non-Zero Net Number Designated - System Name Designated - Sysop Name Designated - Outbound (Hold) Area Designated - Inbound Area Designated If any of these parameters are not designated or are improperly designated as noted, then an errorlevel 254 exit is performed. These parameters are designated in the configuration file. **** Errorlevel values allowed by DOS are from 0 to 255. BinkleyTerm Version 2.30 - User's Guide - Page 26 Therefore, the value of a 38,400 baud exit "wraps" around to equal 128, instead of 384. ***** The external mail program functionality features configurable exit values, but the default value is 99. Making Errorlevels Work For You You, the user, define ALL errorlevels associated with the E1=, E2= and E3= exits, setting them in BINKLEY.EVT. You 'program' a specific task to occur at the beginning of a selected BinkleyTerm "event" (time interval) by selecting a unique "E1=" code for that task. The task can be set to occur periodically throughout each day, once-per-day, once-a-week or on selected days within the week; further, you may execute a given task at different times on different days, if so desired, depending on the way a particular event is configured. Similarly, by having a variety of E2= and E3= codes, you can use different mail unpacking routines throughout the day or week. Refer to the section "Scheduling Events" in the Reference Guide for details. You customize the operation of your BBS or Point to meet your specific needs and those of your "customers". Errorlevels, Batch Files and ExtrnMail This BinkleyTerm option is intended for invocation of an external mail handling program, possibly an alternate mailer, upon reception of a user-defined string of characters. It can also be used to set-up multiple BBS installations, allowing a user to specify which BBS he or she wants. This is covered in detail in the sections "External Mail Programs" and "User-Selected BBS Functionality" elsewhere in this manual. Errorlevels, Batch Files and Housekeeping Another common application of exits and exit values is for housekeeping. For example, the author set up his Point system to do daily housekeeping (deleting and renumbering of the message base) daily at 8:00am. Twice a day, at 4:00am and 11:00pm, his Point polls his BossNode. Each Saturday, the Point requests the current NODEDIFF from the BossNode and, then, on Sunday, processes the weekly NODELIST. A distinct E1= errorlevel handles each task. Thus, only you can prevent chaos and create an orderly functioning batch file for your BBS or Point. Be vigilant, and avoid re-using the same errorlevel for several different tasks. DOS Shell Keys There are also 9 programmable DOS shell exits which are invoked BinkleyTerm Version 2.30 - User's Guide - Page 27 by using Alt-Fx key combinations. You enable and set these up in the configuration file. Look for 'Shell' near the end of the sample BINKLEY.CFG file included with BinkleyTerm, and refer to the section "Configuration File," the command 'Shell' in the Reference Guide. These shells produce NO errorlevels but are mentioned because they are an alternate and/or additional solution to creating Sysop controllable exit/task options. When configured, these shell keys invoke a new copy of the command processor, COMMAND.COM. You may not want to use these as they consume extra memory for the 2nd copy of COMMAND.COM. Using Errorlevels How do you use errorlevels? By testing for their existence with the batch file statement: IF ERRORLEVEL n GOTO xxx Where: n is a numeric value xxx is a label within the batch file Bear in mind the following Rules: The "IF ERRORLEVEL ... " statements must follow immediately after the program they test. "IF ERRORLEVEL n" returns true for any value GREATER THAN or EQUAL TO "n", therefore, Test errorlevels in descending numerical sequence, and, Trap unwanted exit codes so that a step will be executed if, and only if, the desired errorlevel is encountered. In this excerpt from a batch file, the "Start_BT" label refers to a section that loads BinkleyTerm: IF ERRORLEVEL 21 GOTO Start_BT <- Traps 21 to etc. * IF ERRORLEVEL 20 GOTO OpenMail <- Branch & Open Mail IF ERRORLEVEL 11 GOTO Start_BT <- Traps 11 to 19 * IF ERRORLEVEL 10 GOTO Start_BT <- "Non-Event" IF ERRORLEVEL 3 GOTO Start_BT <- Traps 3 to 9 * IF ERRORLEVEL 2 GOTO Bad_Exit <- Nodelist Entry Error IF ERRORLEVEL 1 GOTO Exit_BT <- Branch to 'Exit' * Invalid responses are 'trapped', BinkleyTerm restarts. What Now? Look at some "good" examples which demonstrate automating BinkleyTerm Version 2.30 - User's Guide - Page 28 processes using batch files and errorlevels. In particular, look at the samples provided by Bob Hartman and Alan Applegate for BinkleyTerm (available from 1:104/36), or samples that existing BinkleyTerm Sysops may be able to provide you. Then, make up your own batch file to control a process. Or, take one of the samples and modify it for your specific needs. Have fun! Hack away! Consult the documentation for each of your application programs, determine whether or not it produces errorlevels, and how you can take advantage of them. Errorlevel and Batch File Hints and Kinks When looking at sample batch files, note carefully how each author organized the program logic in his batch file. Here are some reminders. A batch file loses 'control' if it merely invokes another batch file (e.g. you execute a second batch file within the first); instead, "shell out" to DOS from the first batch file by invoking another copy of COMMAND.COM. Using the /C switch closes that second command processor when the second batch file finishes. Consult your DOS reference materials for more information on this point. Examples: COMMAND.COM /C Pak_Mail.BAT or: %comspec% /C Pak_Mail.BAT This is true for all MS-DOS versions up to and including 3.2. MS-DOS/PC-DOS 3.3 introduced the batch command CALL which overcomes this limitation, when it is used. Refer to your DOS manual. Sometimes, your batch file must "remember" what it is doing. You can accomplish this by "setting" an environment variable, for example: SET PROC=UNATTENDED Your batch file can then determine its "logic path" or invoke other programs using statements such as: IF %PROC% == UNATTENDED GOTO xxx or: IF %PROC% == UNATTENDED BT UNATTENDED BinkleyTerm Version 2.30 - User's Guide - Page 29 or: IF %PROC% == UNATTENDED %comspec% /C Pak_Mail.BAT In the above examples, the program follows a certain logic path and performs specific tasks when it's in the unattended mode. Verify that you have sufficient environment space for any variables which you want to "store" in it. Review the section concerning the SHELL entry for CONFIG.SYS in your DOS reference material. This will explain how to enlarge the environment space if that is needed. The exact adjustments which you may need to make are dependent upon your version of MS-DOS/PC-DOS, and several other factors such as memory use, size of DOS paths and so on. You can also pass a variable into a batch file when you invoke a program. For example, the author's POINT.BAT batch file immediately comes up in the Unattended Mode if you invoke it with: POINT -u (or, POINT -U) POINT.BAT then leapfrogs directly into unattended mode using the following statements: IF %1 == -u SET PROC=UNATTENDED IF %1 == -u GOTO Start_BT ... :Start_BT IF %PROC% == TERM BT <-Terminal Mode IF NOT %PROC% == TERM BT %PROC% <-Other Modes Finally, use of errorlevels is not always necessary. Some programs provide an alternative which may meet your needs. For example, ConfMail and some editors produce an ".OUT" file containing the name of each EchoMail area for which mail has been received or created. Thus, test for the existence of the .OUT file rather than testing the errorlevels and, thereby, simplify the logical branching in your batch (.BAT) file. For example: if exist AREAS.OUT ConfMail Export ... -F AREAS.OUT if exist AREAS.OUT del AREAS.OUT or: if exist ECHO.OUT ConfMail Maint ... -F ECHO.OUT if exist ECHO.OUT ReplyLnk -F ECHO.OUT if exist ECHO.OUT del ECHO.OUT The point here is that such an .OUT file can be used by several programs serially, as in the last example, and thus, avoid using BinkleyTerm Version 2.30 - User's Guide - Page 30 errorlevel driven logic. Further, it can continue working for you after you have "lost" your errorlevel by running another program. Environment Variable In environments where multiple drives and paths are used, it is generally a good idea to set a DOS environment variable named BINKLEY. BinkleyTerm can then use this variable to determine where its configuration file is located, should it not be located in the current directory. Place in your AUTOEXEC.BAT file (or in the batch file that starts BinkleyTerm) the line: SET BINKLEY=C:\PATH Where C:\PATH is the drive designator and complete path name where the configuration file is located. CONFIGURATION FILE Most BinkleyTerm parameters are set through a configuration file. By default, the configuration file is named BINKLEY.CFG, and is expected to be available unless a different configuration file is specified on the command line. A sample BINKLEY.CFG files is included with the distribution package. You can edit the file with any plain text editor, such as DOS' own EDLIN. The Reference Guide contains a complete listing of all BinkleyTerm configuration statements and their proper use. BinkleyTerm directly uses the raw configuration file, and each time the program in invoked, BinkleyTerm will scan and process the file, setting internal values to those that you have selected. When you first install BinkleyTerm, or if you change your address ('Address'), inbound files area ('NetFiles'), outbound files area ('Hold'), or NetMail message area ('NetMail') as specified in the configuration file, you must run a special program included with the distribution package called "BTCTL". BTCTL BTCTL is used to create two files based on information in the BinkleyTerm configuration file. First, it produces MAIL.SYS, a Fido-compatible system file used by many mail processing programs. Second, it produces BINKLEY.PRM, a file used by oMMM, a mail packer nearly always used with BinkleyTerm. Note! BTCTL needs to be run only under the circumstances mentioned above. BTCTL DOES NOT need to be run for minor changes BinkleyTerm Version 2.30 - User's Guide - Page 31 to the file that DO NOT include address, inbound file path, outbound file path or NetMail message path. NODELIST The listing of FidoNet compatible systems in your network is called a 'nodelist.' Once a current nodelist is obtained, it can be kept up-to-date by using so-called NODEDIFF files that are distributed weekly within the network. The nodelist and update files are distributed in 'raw' form. Adjunct software must be used to process and compile the raw nodelist and NODEDIFF files into a form usable by BinkleyTerm. From now on, when we refer to "nodelist" we're referring to the compiled, ready-to-use nodelist data files, not the raw nodelist file as distributed within the network. BinkleyTerm is capable of using a variety of compiled nodelist formats. If you do not already have a BinkleyTerm-compatible format that you desire to use, the primary formats supported by BinkleyTerm are the Opus 'Version 5' nodelist, used by Opus-CBCS 1.03b and below, and the Opus 'Version 6' nodelist, used by Opus 1.10 and above. THE VERSION 5 NODELIST SHOULD BE CONSIDERED OBSOLETE. THE VERSION 6 FORMAT OR THE QUICKBBS FORMAT (DISCUSSED LATER) ARE THE PREFERRED FORMATS FOR BINKLEYTERM, AS SEVERAL IMPORTANT FEATURES ARE UNAVAILABLE WITHOUT THEM. Point installations do not need a nodelist at all if they don't care to have one, simply by using all of the following configuration file statements: - BossPhone - BossPwd - PrivateNet - Address Of course, this requires establishing a session password with your boss (as designated by the 'BossPwd' statement). With this method, Terminal Mode must be used to poll the boss using the Alt-Y keystroke, as Unattended Mode will not operate without a nodelist available. Refer to appropriate sections of the manual for additional information. FIDOUSER.LST The nodelist processing software is also used to produce FIDOUSER.LST, a list of Sysop names and node address that BinkleyTerm can use when dialing out. When this file is available to BinkleyTerm, you can enter a Sysop name in place of a node address whenever prompted to enter a node address. This applies to both Unattended and Terminal Modes, while polling or dialing a system. BinkleyTerm Version 2.30 - User's Guide - Page 32 FIDOUSER.LST should be kept in the same sub-directory as the compiled nodelist files are kept. Version 5 Nodelist Although this nodelist format is the BinkleyTerm default (for backward compatibility), it is considered obsolete for use with the current version of BinkleyTerm. If you are running a Fido 11w or Opus 1.0x system, BinkleyTerm can support this nodelist format, but it is highly recommended that you produce both a Version 5 and a Version 6 nodelist for your system; the former for your BBS software, and the latter for use by BinkleyTerm. Again, the Version 5 nodelist is considered obsolete, and should not be used unless absolutely necessary. Version 6 Nodelist Using the Version 6 nodelist allows BinkleyTerm to have more information at its fingertips, specifically, whether a given node in the nodelist supports 'Continuous Mail.' Some nodelist processors are also able to put modem type information into a compiled Version 6 nodelist. The extended information in a Version 6 nodelist allows for automatic determination of this information, resulting in fewer errors that result from attempts to manually compensate for such variables. The Version 6 nodelist is a relatively new format. Nodelist processor commands mentioned in this section apply only to ParseLst, a commonly available nodelist processing package. You will be able to locate ParseLst from systems that normally carry Opus or BinkleyTerm. Other nodelist processors may also support this format, and their specific commands may vary. Make certain that you also make the necessary changes to your configuration file. Add the 'NewNodelist' statement, and change your event schedules to be compatible as well. Refer to the Reference Guide for additional information. Please note that the index files for the Version 5 and Version 6 nodelists ARE IDENTICAL. Therefore, you may use BOTH lists SIMULTANEOUSLY. This is helpful in installations where Opus-CBCS 1.0x or Fido 11w is used under BinkleyTerm. With ParseLst, you'll need to use the following statements in the ParseLst configuration file in order to process a nodelist for BinkleyTerm's use: UseZone, Complete, and Version6. Don't forget to use 'NewNodelist' in BinkleyTerm's configuration file. QuickBBS Nodelist BinkleyTerm also supports the QuickBBS Version 2.0x nodelist. This nodelist format is equivalent in functionality to the BinkleyTerm Version 2.30 - User's Guide - Page 33 Version 6 nodelist described above, including automatic determination of whether a node can accept Continuous Mail. In order for the QuickBBS nodelist to be used with BinkleyTerm, it MUST be processed by ParseLst Version 1.01 or higher. At this writing, Qnode, the nodelist processor included with QuickBBS, does not support the extended information BinkleyTerm requires from the nodelist. ParseLst will insure that the information is included, as well as provide complete compatibility with QuickBBS. Other nodelist processors, such as XlaxNode, should also be able to produce a QuickBBS nodelist that contains the necessary information for BinkleyTerm to function properly. To use this format, add the statement 'QuickNodelist' to your configuration file. Refer to the Reference Guide for additional information. TBBS Nodelist BinkleyTerm can use the nodelist format supported by TBBS. In order to obtain additional information about the various nodes in the list, BinkleyTerm requires an adjunct file, NODELIST.EXT. The nodelist is first processed normally for TBBS. Then, ParseLst is used to produce NODELIST.EXT and NODELIST.IDX from the raw nodelist. These files are then used together by BinkleyTerm to provide full functionality as described above for the Version 6 nodelist. This includes automatic determination of whether a node can accept Continuous Mail. PLEASE NOTE! The TBBS format DOES NOT provide sufficient information to allow BinkleyTerm's zone support to be active. If you use this format, YOU MUST ALSO USE the 'NoZones' statement in your configuration file. Refer to the section "Zone Support" for additional information. To use this format, add the statement 'TBBSNodelist' to your configuration file. Refer to the Reference Guide for additional information. Also refer to the ParseLst documentation for more information about compiling NODELIST.EXT. Nodelist Support Information The authors of BinkleyTerm are willing to consider supporting additional nodelist formats. To facilitate the support of your nodelist format, the following information is required: 1. C language structure definition for the format. (Pascal is acceptable too, but C is preferred.) 2. Definitions of any of the fields in the format. In particular, bit fields must be defined, and the contents of any field that is not obvious must be given. BinkleyTerm Version 2.30 - User's Guide - Page 34 3. Compiler and instructions for generating the given nodelist format. 4. Examples of C code to look-up a given zone:net/node.point number in the nodelist. (Note that any code used will be given out for free in source form, so this should not be taken lightly.) 5. A phone number and hours when the author can be reached if there are issues that need to be resolved. 6. IMPORTANT! A good reason why we should include the format. 7. IMPORTANT! If this is for BinkleyTerm front-ending for a certain type of BBS, the author should include configuration files, batch files, etc. that will be necessary for others to use BinkleyTerm and his BBS. This will save us a lot of work tracking these things down in the long run. If all of this information is forwarded to 1:132/101, 1:141/491 or 1:104/36 we can get back to the author within a week or two to tell them whether the format will be in the next release. ZONE SUPPORT Zones are a high-level addressing scheme devised for use within FidoNet. In a full FidoNet address, such a 1:104/36.0, '1' would be the zone, '104' the net, '36' the node number, and '0' the point number. Currently, zone addressing is not supported within the FidoNet message or packet structure, allowing software such as BinkleyTerm to provide only "kludged" support of zones. BinkleyTerm offers such support, and endeavors to make it as seamless as possible. If for some reason you do not wish zone support to be active, place the statement 'NoZones' in your configuration file. This will cause BinkleyTerm to essentially "turn off" zone support. If you intend not to use zone support, then use the 'NoZones' configuration file statement. If you have not used the 'NoZones' statement, BinkleyTerm will assume that a full, zone-based nodelist is available for its use. For information on how to properly compile a nodelist for BinkleyTerm, refer to the section "Nodelist" for more information. When attempting to send mail to nodes in other zones, BinkleyTerm will assume that mail for other zones will be held in separate outbound areas by zone number. For example, if your outbound mail directory is C:\BT\OUTBOUND, mail for your zone will be held there. However, mail for nodes in zone 2 would be expected in C:\BT\OUTBOUND.002, mail for zone 3 would be expected in BinkleyTerm Version 2.30 - User's Guide - Page 35 C:\BT\OUTBOUND.003, and so on. This example is for zone 1. The zone number for which your default outbound directory applies is determined by the FIRST appearance of the 'Address' statement in your configuration file. Subsequent 'Address' statements identify your alternate identities within other zones (and/or networks). For example, if the first 'Address' statement designates an address in zone 2, then the outbound area designated by the 'Hold' statement in your configuration file is the default, and mail to other zones would require their own distinct outbound areas with extensions that match the zone number. The multi-zone outbound areas are in hexadecimal. For example, the outbound area for zone 10 would be C:\BT\OUTBOUND\.00A. Using this method, it is possible to support up to 4,095 zones. Your mail packer also needs to support the discrete outbound areas for multiple zones. oMMM versions greater than 1.30 support them, as well as the MOOO package. oMMM is commonly available wherever BinkleyTerm or Opus-CBCS files are available. MOOO is also available from many such locations. MULTIPLE NETWORK OPERATION Operation of a system within multiple networks is becoming increasingly popular. Normally, networks such as AlterNet, EggNet, RBBS-Net and so on are implemented as separate zones. To facilitate operation of a BinkleyTerm system within multiple networks, you may specify a separate system address, each with a different zone. For example, if you wish to use a different address for FidoNet (currently zones 1, 2, 3 and 4) and for two alternative networks, you might have the following in your configuration file: Address 1:1010/89.0 Address 9:569/999.0 Address 11:334/1.0 If your system connects with a system in zone 9, your system will identify itself as 9:569/999. If connected with a zone 11 system, it will identify itself as 11:334/1. The first 'Address' statement is the default, and callers in zone 1 (and any zones other than 1, 9 and 11 - those specified with 'Address' statements) would find your system identified as 1:1010/89. SECURITY In the ideal world, we would not need locks, police, or jails; there wouldn't be crime. But we don't live in an ideal world, and for this reason, BinkleyTerm offers a selection of features that are intended to offer your system a certain level of security against "electronic mail crime." BinkleyTerm Version 2.30 - User's Guide - Page 36 The existence of security features is not intended to evoke fear. Chances are excellent that you will have no need for security features in most cases. But just as high crime areas see more locks and iron gates than low-crime areas, the choice of how much security to put in place is up to you, and is based on your needs and experience. BinkleyTerm's internal security is based on a simple principle. With the exception of session passwording, for each secured feature (all of which are specified within the configuration file), there is a default statement. When you implement no security features, the default statement is used to specify a particular feature's configuration. Prot When security is implemented, however, two more statements are used in addition to the default. One type of statement, known as "Prot" for "protected," describes a group of systems with which you have implemented session passwording. These links are "protected" by passwords. When session passwording is implemented, unless a password is matched when connecting to a protected system, a mail session is aborted. "Protected" or "Prot" systems are the top-level, or "most favored" situations, since you generally know the other person at the other end (a pre-requisite to establishing a password). Known The second type of statement is called "Known" and describes systems that are listed in the nodelist ("known" to you) but with whom you have not established a session password. These are links with listed systems, but links that are not password protected. This group represents the middle-level of security. Default When you use a Prot and/or a Known security feature, then the default statements all take on a new meaning - that of unknown systems. The defaults are used for links that are not in the nodelist, and therefore, cannot have a session password established. This group of systems represents the lowest-level of security, since you really have no idea who owns such systems, or where they are located. Security - Session Passwording BinkleyTerm supports session-level password protection. Using such protection helps prevent situations where someone uses a FidoNet mailer to 'impersonate' a legitimate FidoNet node, and BinkleyTerm Version 2.30 - User's Guide - Page 37 pickup mail addressed to the node. When implemented, both the sending and receiving systems must have it in operation, with the same password on both ends (exceptions noted below). With Point systems, passwording can be automatic. Simply use the 'BossPwd' configuration file option, and choose a password. Make sure your Boss also uses the same password. For other types of systems, password information is kept in the nodelist data file. ParseLst (and some other nodelist processors) can easily add a password to a nodelist entry during processing. Refer to the documentation for your nodelist processor. When talking with other BinkleyTerm, Opus or compatible systems that use the YooHoo session negotiation method, full, two-way protection is available. The systems connect and exchange the password when the YooHoo takes place. If the passwords do not match, the session is terminated, regardless of who initiated the call. The only exception is when you have a password implemented, but the remote has NO password implemented. In this case, if YOU placed the call, then a session will still occur. If the REMOTE placed the call, then the session will be aborted. When connected with SEAdog and compatible systems, password matching takes place only when you are picking up mail from the remote system. You may send to a SEAdog system without a password match taking place. (The assumption is that you always know who you're calling, but don't always know who's calling you.) Note that session passwords must not exceed eight (8) characters, and are case insensitive. When BinkleyTerm cannot find a password for a remote system when placing a call, it will not check for a password during the session. This responsibility is left to the remote system, if the remote chooses to perform checking. BinkleyTerm allows easy implementation of new passwords. Simply add the agreed upon password as outlined above, and send the remote system a message. BinkleyTerm will allow an outbound session to take place in cases where you have designated a password, but the remote has not yet implemented it. This is handy for letting a remote system know that a password was implemented. Note that in this case, BinkleyTerm will NOT allow the remote to have a successful session when the remote calls your system; only when you place the call (as stated above, the idea is that you know who you're calling, not who's calling you). Security - Secured Inbound File Areas Another method of securing the flow of mail involves controlling the processing of incoming mail to your system. In most cases, BinkleyTerm Version 2.30 - User's Guide - Page 38 you will want to protect common mail links with session passwording, as outlined in the previous section. Still, the potential exists for another abusive system to send you rogue mail, or mail "planted" onto your system in hopes that it will be routed to another system at your expense, or find its way into a national EchoMail conference. The following list shows the various security levels and the configuration file statements that define their respective inbound paths: Prot 'ProtInbound' Known 'KnownInbound' Default 'NetFile' In a typical installation secured in this manner, mail will automatically be processed only if received to the 'ProtInbound' area. Mail received to 'KnownInbound' or 'NetFile' must be examined and processed manually. Of course, you could choose to configure your system in a such a manner that mail received in any of the three areas is processed automatically to your liking, possibly to special message areas. The only "hole" in this is with FSC-0001 sessions, such as those with SEAdog or Fido. Since BinkleyTerm has no way of knowing the address of the sending system until a packet is received, that first packet (.PKT file) will always be placed in the default area specified by the 'NetFile' statement. Secured inbound file areas simply provide another, extra measure of handling potential security problems associated with the reception of "rogue" or "planted" mail. Security - Controlling File Requests BinkleyTerm offers a method of establishing limitations on file requests received from systems that are not session password protected, or are not found in the nodelist. This support is optional; if you do not wish to limit file requests in this manner, use only the files and configuration file statements mentioned in the section "File Requests." The following table lists these possibilities, the file types (as described in the section "File Requests") and the respective configuration file statement used: Prot ABOUT 'ProtAbout' AVAIL 'ProtAvail' OKFILE 'ProtReqList' Maximum 'ProtReqLim' Known ABOUT 'KnownAbout' BinkleyTerm Version 2.30 - User's Guide - Page 39 AVAIL 'KnownAvail' OKFILE 'KnownReqList' Maximum 'KnownReqLim' Default ABOUT 'About' AVAIL 'Avail' OKFILE 'Okfile' Maximum 'MaxReq' Essentially, the default files and configuration file statements described in the section "File Requests" are used for all file requests by default unless a higher "Known" or "Prot" statement is used. Note that all file request controls apply to update requests and function requests as well. Security - Response File Templates Refer to the section "Request Response Files" for information on their operation and use. It is possible to designate separate response file templates for each of the three security levels. Generally, you won't want or need to do this unless security controls on file requests have been implemented. The security levels and their respective configuration files statements for secured response file templates are: Prot 'ProtReqTpl' Known 'KnownReqTpl' Default 'ReqTemplate' BBS INTERFACE One of the most common uses of BinkleyTerm is as a mail front-end for a bulletin board system, or BBS. BinkleyTerm offers three different methods for passing control to a BBS. The method you use is determined by a configuration file statement (refer to the Reference Guide for details). BBS Exit The 'BBS Exit' option will cause BinkleyTerm to exit to the start-up batch file with an errorlevel of the baud rate divided by 100 upon receipt of a non-mail call. For example, a 300 baud caller exits to the batch file with an errorlevel of 3, a 2400 baud caller at errorlevel 24. The batch file then detects the errorlevel, and jumps to a section of the batch file you designate to start the BBS program BinkleyTerm Version 2.30 - User's Guide - Page 40 with the required information. The batch file should recycle and restart BinkleyTerm once BBS use is terminated. BBS Spawn The 'BBS Spawn' option causes BinkleyTerm to stay resident when a caller accesses the BBS. BinkleyTerm will execute the following command as a child process: spawnbbs <baud> <port> <time> <modem_info> SPAWNBBS.BAT is the name of a batch file you create. <baud> is the baud rate of the connection, <port> is the communications port number used for the call, and <time> is the number of minutes to the next non-BBS-allowed event (as designated in your configuration file event schedules). <modem_info> is intended primarily for RBBS-PC installations where extended modem connect information may be desired. For example, USRobotics HST modems might issue the connect message "CONNECT 9600/ARQ" in which case the <modem_info> parameter would be "/Arq" indicating a "reliable" connection. Note that in this parameter, only the first letter of each "word" will be capitalized (as shown in the example). The batch file can use the parameters passed to it with standard DOS conventions. %1 designates the first parameter (baud rate in this case), %2 the second parameter (port number), and so on. Opus might be started from SPAWNBBS.BAT with this command line: opus bbs -b%1 -p%2 -t%3 Refer to the documentation for your particular BBS for the command line information that can be passed to the BBS. The primary disadvantage of the 'BBS Spawn' option is that BinkleyTerm stays memory resident while the BBS operates. This could cause memory availability problems on some systems. Be certain to check the memory requirements of your BBS software. If you choose to use the 'SwapDir' configuration file option, the 'BBS Spawn' option will be workable. Using 'SwapDir' causes BinkleyTerm to leave only a small kernel of itself in memory when performing DOS shells, making available substantially more memory than would otherwise be available. Refer to the Reference Guide section "Configuration File" for additional information. BBS Batch The 'BBS Batch' option uses the best of both of 'BBS Exit' and 'BBS Spawn.' BinkleyTerm still exits to the start-up batch file, but prior to exiting, BinkleyTerm physically writes to the disk a batch file named BBSBATCH.BAT, which contains a single line. An example of BinkleyTerm Version 2.30 - User's Guide - Page 41 the contents of this file might be: spawnbbs 2400 1 47 /Arq The information is the baud rate, port number and time in minutes to the next non-BBS event. In this case, there is a 2400 baud caller, on COM port 1, with 47 minutes remaining to the next non- BBS event, and a modem information string of /Arq. After writing this file, BinkleyTerm exits as does the 'BBS Exit' option, with an errorlevel of the baud rate of the caller divided by 100. The start-up batch file should simply start execution of BBSBATCH.BAT by adding the line "bbsbatch" to the file, and jumping to the line whenever a human caller is on-line. In other words, regardless of the baud rate of the caller, BBSBATCH.BAT should be invoked. Once invoked, BBSBATCH.BAT will invoke SPAWNBBS.BAT with the necessary parameters that include the baud rate, port number, and minute to the next non-BBS event. SPAWNBBS.BAT would physically invoke the BBS with the proper command lines. When use of the BBS is complete, this batch file should re-invoke the BinkleyTerm start-up batch file. Using this 'BBS Batch' method of accessing the BBS, BinkleyTerm can still provide all the information of the 'BBS Spawn' method, without the necessity of staying resident. BinkleyTerm Version 2.30 - User's Guide - Page 42 BBS Batch Method Flowchart The 'BBS Batch' method of accessing BBS software is confusing to many BinkleyTerm users. For further clarification, a flowchart of this method is shown here: +-----------------------+ | Wait for Call | <-------------+ +-----------------------+ | | | v | No +-----------------------+ | Mail <------| Human Caller? | | +-----------------------+ | Yes | | v | 300 +-----------------------+ 1200 | +------| Baud Rate |------+ | | +-----------------------+ | | | 2400 | | 9600 | | +--------+ | | +--------+ | | | | | | v v v v | +-----------------------+ | | Invoke BBSBATCH.BAT | | +-----------------------+ | | | v | +-----------------------+ | | Invoke SPAWNBBS.BAT | | | w/ Parameters | | +-----------------------+ | | | v | +-----------------------+ | | Invoke BBS System | | | w/ Parameters | | +-----------------------+ | | | +---------------------------+ Banner When a file named BINKLEY.BAN is present in the directory that BinkleyTerm is invoked from, the file will be displayed to callers immediately after the BinkleyTerm identification line. The file is a flat ASCII text file, and may contain extended information for the benefit of callers. BinkleyTerm Version 2.30 - User's Guide - Page 43 EXTERNAL MAIL PROGRAMS BinkleyTerm can be used with external mail programs, such as UUCP. When an 'ExtrnMail' statement is used in the configuration file, BinkleyTerm will answer the phone and wait for a YooHoo or TSYNC (the start of a mail session) or a string you designate with the 'ExtrnMail' option. When the designated string is received from the remote system, BinkleyTerm will send the string associated with the 'MailNote' configuration file option (if any), then will physically write a batch file called MAILBAT.BAT to the disk, and exit the start-up batch file with an errorlevel as given with the 'ExtrnMail' statement, or with errorlevel 99 if none was given. MAILBAT.BAT contains a single line: EXTMAIL <baud> <port> <time> <errorlevel> <modem_info> Where <baud> is the baud rate of the caller, <port> is the COM port number, and <time> is the time in seconds to the next non- BBS event, <errorlevel> is the errorlevel number used to exit the original batch file, and <modem_info> is extended modem connect information. <errorlevel> will be the same as that given with the 'ExtrnMail' statement in the configuration file, or "99" if none was given. <modem_info> is intended primarily for RBBS-PC installations where extended modem connect information may be desired. For example, USRobotics HST modems might issue the connect message "CONNECT 9600/ARQ" in which case the <modem_info> parameter would be "/Arq" indicating a "reliable" connection. Note that in this parameter, only the first letter of each "word" will be capitalized (as shown in the example). Notice the similarity in concept between this and the 'BBS Batch' method of invoking a BBS (as described previously). When BinkleyTerm exits with the previously defined errorlevel, your batch file must capture the errorlevel and invoke MAILBAT.BAT, which will in turn invoke EXTMAIL.BAT with the various command line parameters shown above. EXTMAIL.BAT is then used to invoke the external mail program of your choice, taking the needed command line parameters as supplied by the batch file, and processing and/or using them as needed. Once the external mail program session has been completed, your original start-up batch file for BinkleyTerm should be invoked to place BinkleyTerm on-line again. USER-SELECTED BBS FUNCTIONALITY An additional use for the external mail functionality described in the previous section would be to allow multiple BBS systems to reside at the same telephone number, and to give BBS users the BinkleyTerm Version 2.30 - User's Guide - Page 44 ability to select the desired BBS from a menu. It would be possible to run completely separate systems, to run the same system with different BBS packages, and so on. This section will give an overview of the procedure. Basically, 'ExtrnMail' statements in the configuration file are used to build the menu options themselves. If you want to exit to the batch file when a user presses 'A' on their terminal, then a configuration file entry like this would be needed: ExtrnMail 130 A This would cause BinkleyTerm to write MAILBAT.BAT to the disk, and exit to the batch file with an errorlevel of 130. As described in the previous section on external mail programs, your batch file should invoke MAILBAT.BAT, which in turn invokes EXTMAIL.BAT. EXTMAIL.BAT would be the batch file that acts upon the choice, and physically invokes the desired BBS program. If you want the choices to be case-insensitive, then two 'ExtrnMail' statements would be needed for each letter, like this: ExtrnMail 130 A ExtrnMail 130 a This would cause BinkleyTerm to use errorlevel 130 when either 'a' or 'A' is received from the user. The menu presented to users should be kept in a file called BINKLEY.BAN (refer to the "Banner" section for more information). This file might look like this: Welcome to Multi-System 100. Please choose the desired BBS: A - "Garden Central" Using QuickBBS Software B - "Margarita Bay" Using Opus-CBCS Software C - "Margarita Bay" Using Fido 11w Software Make your selection by letter... Such a menu would allow users three options. Each lettered option would require a separate 'ExtrnMail' statement in the configuration file; two each if case insensitivity is required. The string "Make your selection by letter..." is NOT contained in BINKLEY.BAN, but rather, is added with a 'Banner' statement in the configuration file so that the line is re-displayed each time a user makes an incorrect choice (refer to the Reference Guide section "Configuration File" for information). Once the user has made a selection, and MAILBAT.BAT is invoked and in turn EXTMAIL.BAT is invoked, then the batch file must determine which selection is made and act upon it. BinkleyTerm Version 2.30 - User's Guide - Page 45 In EXTMAIL.BAT (where the BBS systems are invoked), the top of the batch file should make a determination as to which choice was given by the user. One of the parameters on the command line when EXTMAIL.BAT is invoked by MAILBAT.BAT is the errorlevel which corresponds to the choice the user gave (as designated by an 'ExtrnMail' statement in the configuration file). A section of the batch file might look like this: if %4 == 130 goto bbs1 if %4 == 140 goto bbs2 if %4 == 150 goto bbs3 The fourth parameter given on the command line is the errorlevel value, and is reference by "%4" as shown. For example, if the errorlevel that corresponds to the choice was 130, then batch file execution would jump to the "bbs1" label, and invoke a particular BBS program. Please note that the default is for a user to press the "escape" key to enter the BBS. One of the BBS systems should be setup as the default system as described in the section "BBS Interface." Should a user press "escape," or if the time limit to make a response should expire, the default BBS would be invoked. Note also that the configuration file parameter 'Timeout' should be extended to allow a user more time to read and make a selection prior to making a default exit. A 'Timeout' value of 30 to 60 seconds is suggested. Placing multiple BBS systems on-line at one number takes some work and experimentation in order to operate correctly. Hopefully the tips given here will point you in the right direction. FILE REQUESTS BinkleyTerm supports the two popular file request methods currently in use in FidoNet; "Bark" requests as designed for and used by SEAdog, and "WaZOO" as designed for and used by Opus- CBCS. Either style can be used on an incoming or outgoing basis. To generate an outgoing file request, use one of the many utilities designed for the purpose, such as AMAX, Please, oGet, tGet, etc. Any Opus-compatible file request builder can be used with BinkleyTerm. You may also manually build file requests. They are a single-line flat ASCII text file, and are named in the same manner as packets (refer to the section "How BinkleyTerm Handles Mail" for information on the naming convention) and have a file extension of .REQ. Outgoing requests NEVER should have a drive and path designation; only the file name. The remote system handles the drives and paths. BinkleyTerm Version 2.30 - User's Guide - Page 46 The .REQ file is placed in your outbound holding area. BinkleyTerm will handle .REQ files in the same manner as it does Normal packets (unless an 'X' flag is applied to an event), but you can also manually poll to send the request immediately. Incoming requests are controlled and affected by four files, each of which are designated in the configuration file. The first file, OKFILE, is a machine-read listing of files, complete with drive and path, that you will allow to be sent to remote systems via file request. The file is designated with the 'Okfile' statement in the configuration file. Wildcards are allowed, and nearly always used. When an incoming request is received, the request is checked against the OKFILE to see if you permit the file to be sent. The OKFILE also allows you to implement "magic filenames" which are words used to represent a file. If someone requests "BINKLEY" from you, for example, you could set-up your OKFILE in such a way as to send BEXE_150.ARC in return. This frees the person making the request from having to know the exact filename of the file he wants. This is generally used by systems which are software distribution points, hubs, and so on. Password protection may also be implemented with the OKFILE, making a password required in order to receive a particular file or group of files. A sample OKFILE: b:\aprog.ARC c:\file\stuff\*.* c:\file\programs\wlc*.txt c:\file\private\*.* !mypass @BINKLEY c:\file\dist\bexe_150.arc @MYEDIT !outpass c:\file\private\editmax.arc The first line gives an exact filename. The second and third lines show the use of wildcards. The fourth line shows password protection, with an exclamation point (!) followed by the password. The fifth line shows a magic filename, an 'at' symbol (@) followed by the magic filename, followed by an exact drive, path and filename designation. The sixth line shows a magic filename with password protection. Note that in all cases, a password (if any) is always the second argument in an OKFILE entry. The next special file is the AVAIL file, and is designated by the 'Avail' statement in the configuration file. When someone requests the magic filename "FILES" BinkleyTerm will send this file. It is a list of the files you have available for request, in human readable form. This is a flat ASCII text file, and should feature the name of the file, and usually its size in BinkleyTerm Version 2.30 - User's Guide - Page 47 bytes and a short description of the file. There are utilities available that can construct this file automatically based on your BBS system's internal listings. Of course, it could also be manually created. The next special file is called the ABOUT file, and is designated by the 'About' statement in the configuration file. When someone makes a request for the magic filename "ABOUT" or when someone makes an invalid WaZOO file request, this file is sent by BinkleyTerm. It normally contains a short advertisement about your system, as well as a notification that the calling system could possibly have made an invalid request. Again, this is a flat ASCII text file in human-readable form. The ABOUT file is sent only on failed WaZOO requests. The file is NOT sent on failed Bark requests. Finally, the last item that applies to file requests is the 'MaxReq' statement contained in the configuration file. A quantity is given with the statement which allows you to designate the maximum number of files that will be sent during one file request session. Refer to the Reference Guide section "Configuration File" for more information. It is possible to limit incoming file requests based on some basic criteria. For information, refer to the section "Security - Controlling File Requests." UPDATE REQUESTS Update requests are a method of obtaining an "update" of a file you already have, from another system you believe to have a newer copy. They differ from file requests in that when you construct an update request, you include a drive/path/file specification that points to an existing file on your system. Generally, DOS wildcards are acceptable. When BinkleyTerm connects with the desired remote, it will compare the date and time stamp on your copy of the file(s) to the date and time stamp of the same-named file(s) on the remote system. If the remote system has a newer copy of a given file, it will be sent. If it does not, no file will be sent. Note that the drive and path specification DO NOT need to be the same on the remote system; the drive and path you give refer only to YOUR copy of the file. The remote may have any file structure he or she desires. Update requests were originally implemented in SEAdog, a mailer from System Enhancement Associates, Inc. In addition to supporting update requests with SEAdog systems, BinkleyTerm implements a newly defined WaZOO update request for use other BinkleyTerm systems, or other mailers that support WaZOO update requests. Update requests are most commonly used now to handle GroupMail, a new method of sharing message areas developed by System BinkleyTerm Version 2.30 - User's Guide - Page 48 Enhancement Associates, Inc. GroupMail generally requires update request capability on both ends of the connection. Like file requests, update requests are kept in .REQ files in your outbound area. In fact, a combination of update and file requests can be contained in the same physical .REQ file. An update request entry contains a filename, as well as a date and time code that corresponds to the date and time stamp of the file on your system. Because the date and time code is in a special format, it is not recommended that you attempt to create an update request entry yourself. At this writing, the oMMM mail packer (version 1.30 or higher) and the AMAX outbound utility (version 2.10 or higher) both support the creation of update requests in the manner that BinkleyTerm requires. Refer to the documentation for those programs for additional information on creating update requests. Certainly other utilities will eventually have this ability as well. Please note that in order for update requests to work, the remote system must have the file you want updated available for regular file request. You cannot update a file that would not otherwise be available for file request from the remote system. REQUEST RESPONSE FILES Incoming file and update requests are not always successful. BinkleyTerm supports the ability to dynamically generate a "response file." This file is a plain text file, built "on-the- fly" during a session, and sent in response to a failed (or optionally, a successful) file or update request. If you choose to implement request response files, the "about" file designated in your configuration file will no longer be sent. See "File Requests" for more information. Note that when a response file is sent, it is counted against the maximum number of file sent in response to a request, as designated by the 'MaxReq' statement in the configuration file. See "File Requests" or the Reference Guide section "Configuration File" for more information. The content of the response file is configured by you with a template file. The template file name is designated by the 'ReqTemplate' configuration file statement. As with file requests, you can also implement security controls with the request templates. See "Security - Response File Templates" for more details. Normally, the response file contains information such as the date and time the request was made, what file was requested, and why the request failed. You may wish to include information such as the times your system accepts requests, what magic filenames you support, and so on. BinkleyTerm Version 2.30 - User's Guide - Page 49 Response files are named similar to outbound packets or request files. They are <net><node>.RSP, where <net> is a net number, and <node> is a node number. Both <net> and <node> are four- digit hexadecimal number with leading zeroes. A sample response file template, SAMPLE.TPL, is included with the BinkleyTerm distribution package. Use this sample as a starting point for your own response file template. The complete list of possible verbs for use in the response file can be found in the section "Response File Template" in the Reference Guide. FUNCTION REQUESTS Two additional special entries may be included in the OKFILE that operate similar to magic filenames. Called "magic" function requests, they allow an incoming request to trigger the operation of a program. $ Function Requests The first style uses a dollar sign ($) in the first column of an OKFILE entry, followed by a function request name. If the name is matched, then the command after the password (if any) is executed. In addition, two arguments which correspond to the net and node number of the calling system can be sent if desired by adding "%d %d" to the end of the OKFILE entry. For example: $INFO INFO.BAT %d %d If an incoming file request is for "INFO" then the program INFO.BAT would be executed, and it would receive two command line arguments that correspond to the net and node number respectively. For instance, if 141/491 requested "INFO" then the following would be issued to DOS for execution: INFO.BAT 141 491 Another example of such an OKFILE entry would be: $CLEANUP !mypass CLEANUP.BAT %x %x In this case, a password is included as the second argument of the line, and must be matched by the incoming request in order for the program to be executed. Note also that in this example, "%x %x" was used, and would cause a hexadecimal representation of the net and node number to be sent as command line arguments to the program being executed. In our example, if 104/36 requests "CLEANUP" with a password of "mypass" then the following would be sent to DOS for execution: CLEANUP.BAT 68 24 BinkleyTerm Version 2.30 - User's Guide - Page 50 See "Function Request Notes" below for additional function request information. + Function Requests A second type of function request is also supported, and is designated by a plus sign (+) in the first column of an OKFILE entry. In this case, if the filename and optional password are matched, then the entire line from the incoming .REQ file is passed to DOS for processing, with the <zone>:<net>/<node> address appended as individual arguments to the command line. An example of an OKFILE entry might be: +GETREV !mypass If an incoming .REQ file from 141/491 contained the line: GETREV !mypass BT 1.50 Then the following would be passed to DOS for execution: GETREV !mypass BT 1.50 1 141 491 A program called GETREV would be executed, and would need to process or filter the command line as needed. Function requests are convenient for allowing a remote system to have a batch file or utility of some kind (not included) place a particular file on hold for a node for later pickup, to cause the system to send a particular file, to trigger some other sort of function or activity remotely, etc., etc. If a program called as part of a function request creates a file in the appropriate outbound area called <net><node>.QLO (where <net> and <node> are 4-digit hexadecimal numbers with leading zeroes), BinkleyTerm will treat this file as a legitimate "flow" (file attach) file and send the file(s) listed in it back to the caller as part of the request logic. Function Request Notes If a function request triggers a program or batch file to build a file attach (flow) file, then BinkleyTerm will process the file attach during the current session. In other words, if a file attach is generated during a function request, then the file(s) shown in the file attach will be sent during the current session. Note that the normal logic for the handling of .HLO (Hold file attaches) still applies; i.e., file(s) designated within a .HLO file will be sent only when the destination node polls for pick- up. BinkleyTerm Version 2.30 - User's Guide - Page 51 A WORD ABOUT POINT NETWORKS BinkleyTerm is well suited to the task of being a "boss" (or host system) of a point network. Points are essentially a "system under a system" and allow the point operator to have limited access to the network without the normal requirements of keeping a system on-line at certain hours. Since point addressing is not part of the FidoNet standard at this time, certain "kludges" must be used in order to handle a point network. Essentially, the process involves using a private network address, and assigning node numbers to the points under the boss. For example, 1:104/36.17 (point #17 off of node 104/36) might actually be assigned 1052/17 for the purpose of transacting mail with the boss. For reference purposes the point is 1:104/36.17, but mail is actually held for 1052/17 to pick-up, and the point must call as 1052/17. Often times, private point addresses will make their way into EchoMail "SEEN-BY" lines. This could cause problems down the line if another system uses the same private address. For this reason, IT IS RECOMMENDED THAT YOUR PRIVATE NETWORK ADDRESS BE ASSIGNED BY THE INTERNATIONAL COORDINATOR. The International Coordinator requests that you adhere to this recommendation, and contact him directly for a private network number assignment. As a boss node, you may then use the network address to assign your points their own node address in the private net for the purpose of transacting mail. The International Coordinator can be reached at 1:1/0. To receive a private net number, the information that follows is needed. All information will be held in confidence, but is needed in case the International Coordinator needs to get a hold of the private net administrator. As soon as this information is received, the International Coordinator will issue a private net number: - Name of the Private Network Administrator - Name of the Private Network (if any) - Mailing Address - Voice Phone - Data Phone - FidoNet Node (if any) - Alternate E-Mail Addresses (i.e., Usenet, Bitnet, MCI Mail, Telex, etc., if any) Your cooperation in obtaining an assigned private network number for use on point networks will help ensure network integrity. BinkleyTerm Version 2.30 - User's Guide - Page 52 +-------------+ | +---------+ | | | Section | | BinkleyTerm User's Guide | | 4 | | PROBLEM SOLVING | +---------+ | +-------------+ BINKLEYTERM SUPPORT Since BinkleyTerm is a product which is "free for the asking" you cannot expect a toll-free software support line (as much as we may want to provide you with one). The primary means of support is the BINKLEY EchoMail Conference. This conference is carried worldwide via FidoNet. Contact your EchoMail Coordinator or Hub for information on hooking into the conference, or finding a system that you can use to participate in the conference. The conference is monitored and read by the BinkleyTerm authors and beta testers. A secondary source of support is provided by BinkleyTerm HELP, Shawn Stoddard, at FidoNet 1:1/102.0. If you have an urgent question, or are unable to hook into the BINKLEY EchoMail Conference, send a NetMail message to BinkleyTerm HELP. Replies are issued as time and resources allow, so please be patient. TROUBLESHOOTING 3,000 pages of documentation would not entirely eliminate the potential for problems with the installation and operation of BinkleyTerm. Due to the wide variety of hardware and software configurations that BinkleyTerm may be used with, as well as the varying levels of experience of the BinkleyTerm user, problems will sometimes occur. This section attempts to present common problems and possible solutions. If there is not a solution to your problem presented here, please read over the appropriate sections of the manual again. If you still are having difficulty, place a message in the BINKLEY EchoMail conference, or contact BinkleyTerm HELP at 1:1/102. Baud Rate Locking Trouble Do not use BinkleyTerm's 'LockBaud' configuration file statement. Lock the baud rate of your FOSSIL instead. Outward Dial Aborting Many people installing BinkleyTerm mistakenly use the 'Suffix' option in their configuration file. Unlike most communications programs, BinkleyTerm by default adds a carriage return to the end of the dial string. 'Suffix' is used to add instructions to the end of the phone number, but BEFORE the carriage return. By adding a carriage return code (pipe symbol, |) with the 'Suffix' BinkleyTerm Version 2.30 - User's Guide - Page 53 statement, you are essentially telling BinkleyTerm to send TWO carriage returns, yours, plus the default. With most modems, this will immediately abort the dialing process before it even gets started. In nearly all installations, the 'Suffix' statement WILL BE COMMENTED OUT. If deleting the 'Suffix' statement does not fix the problem, you may also try adding the 'NoCollide' and/or 'SlowModem' statements to the configuration file. Refer to the Reference Guide section "Configuration File" for more details. False Call Collision Reports In some installations, BinkleyTerm may abort the dialing process due to an incoming call, even when there is no incoming call. This is probably due to the modem reporting "RING" on both incoming and outgoing calls. Use the 'SameRing' configuration file option to partially disable the call collision feature; use the 'NoCollide' option to totally disable the feature. FOSSIL Driver Compatibility Problems The two most popular FOSSIL drivers in use with BinkleyTerm are Ray Gwinn's X00 and Bob Hartman's OpusComm, both of which are for the IBM PC and close compatibles. If one of the drivers fails to work correctly in your installation, please try the other. BinkleyTerm Will Not Recognize Node Addresses You have not compiled the nodelist correctly. Use ParseLst to compile a fully-zoned Version 6 nodelist for your system. To do this, make sure the following statements exist within your ParseLst configuration file: UseZone, Complete (or Gated), and Version6. TBBS Difficulty - BinkleyTerm Runtime Errors When used with TBBS, BinkleyTerm must be renamed MAILER.EXE. Since BT.EXE uses overlays to provide more efficient memory usage, it CANNOT be renamed. TBBS users should be certain to use BTBIG.EXE, the non-overlay version, on their systems, renaming it to MAILER.EXE before use. Some TBBS Sysops have patched TBBS.EXE to invoke BT.EXE, which allows them to use the overlaid version. While if this is done correctly it will probably cause no problems, we cannot recommend this course of action. DOS Shell Not Working Correctly BinkleyTerm is developed under Microsoft C. The MSC routines do not use COMSPEC to find COMMAND.COM, which is needed to perform a DOS shell or child process. COMMAND.COM must be found on the DOS path. Refer to your DOS documentation for information and BinkleyTerm Version 2.30 - User's Guide - Page 54 instructions regarding COMSPEC, and the SET PATH command. Zone Support Does Not Operate Correctly Chances are excellent that you have not compiled the nodelist correctly. Although the actual entries for nodes in other zones do not need to be included in the compiled nodelist files, what are called "zone identifiers" DO need to be included in order for zone support to work. See the section "Nodelist" for more information on correct compilation of a nodelist. Another item to check is that outbound areas are created for the other zones to which you want to send mail. See "Zone Support" for information on how outbound areas for other zones are constructed. Date Rollover Problem BinkleyTerm keeps schedule information in binary form in a file named BINKLEY.SCD. If for some reason the file is newer than the current date and time, BinkleyTerm will report "Date Rollover Problem?" as this condition is usually indicative of a problem with DOS rolling the date over at midnight properly. If there appears to be no difficulty with date rollover, delete the BINKLEY.SCD file, and allow BinkleyTerm to contruct a new one the next time it is invoked. A date rollover problem sometimes does exist with certain versions of DOS. If the problem persists, a DOS upgrade may be indicated. GLOSSARY AMAX The name of a BinkleyTerm utility by Alan Applegate that handles various outbound mail manipulation functions. ARCmail Simply archived mail packets, processed with an ARC- compatible utility. Typically used to forward EchoMail messages due to the file compression inherent in the archiving process. Naming conventions correspond to a generally accepted method. See 'Mail Packet.' BBS An electronic bulletin board system. A method of communicating and sharing files with others by computer. Typically operated by hobbyists, free-of-charge. Carrier Detect A serial port line that is brought "high" (raised, given a "true" logical value) when carrier is present on the line, e.g., when the modem is connected to another modem. BinkleyTerm Version 2.30 - User's Guide - Page 55 The modem raises and lowers this line. CD See "Carrier Detect." Compressed Mail Mail that has been compressed or "archived" with any one of several archiving utilities. Such mail is also known as ARCmail, ZOOmail, PAKmail, etc., depending on which archiving utility was used to compress the mail. ConfMail The name of a mail processing program by Bob Hartman for use in the Opus or Fido environments, or any other environment that uses a compatible message base. Continuous Mail A capability of a particular system to accept mail at any time of day, as opposed to being required to accept it only during certain pre-scheduled times. D'Bridge A commercial FidoNet mailer written by Chris Irwin. Data Terminal Ready A serial port line that is brought "high" (raised, given a "true" logical value) when the local terminal is ready for communications. A serial device (in our case a modem) connected to the serial port uses this line to detect whether the terminal (your PC and BinkleyTerm) are ready for communications activities. Normally, bringing the line "low" (lowering, giving a "false" logical value) causes a modem to disconnect from the telephone line. BinkleyTerm raises and lowers this line. DTR See "Data Terminal Ready." Dutchie A FidoNet mailer written by Henk Wevers. Dynamic Event A system event (see "Event") that stops when particular BinkleyTerm Version 2.30 - User's Guide - Page 56 conditions (lack of mail of a certain type to be sent) are met. EchoMail A system devised by Jeff Rush for the automated sharing of message areas between systems, whereby messages are "echoed" from one system to another. Also known as conferences or EchoMail conferences. Errorlevel The name of a DOS environment variable; contains a value returned by a program on exit that indicates a certain pre- defined condition. Event A system occurrence at a pre-configured time, day-of-the- week, and/or date. Normally system limitations such as when to dial long distance are dependent on system events. Fido The original implementation of FidoNet and FidoNet protocol; a BBS software package. FidoNet The name of the original network that used FidoNet protocol, as designed by Tom Jennings. FidoNet Protocol A method of electronic mail transfer designed by Tom Jennings, as documented in the Fido Technical Standards Committee document FSC-0001. File Request The ability and associated methods of using extended FidoNet protocol to obtain a particular file automatically from one FidoNet system to another. FOSSIL Driver FOSSIL is an acronym for Fido/Opus/SEAdog Standard Interface Layer. Since not all computers capable of running MS-DOS are hardware compatible with the IBM PC, communications software typically written for the IBM PC may not operate on machines such as the DEC Rainbow, Sanyo 555 or Heath/Zenith 100. The FOSSIL provides a consistent manner for a communications BinkleyTerm Version 2.30 - User's Guide - Page 57 program to access the communications ports, keyboard and screen. The FOSSIL is typically installed at boot-time, either as a device driver or as a program. The driver MUST be installed prior to running any FOSSIL compatible software, BinkleyTerm included, or an error message will be generated, and the program will abort. FOSSIL drivers are normally available from systems that distribute Opus-CBCS and/or BinkleyTerm software. Examples of FOSSIL drivers are: OpusComm by Bob Hartman for the IBM PC and close compatibles, X00 by Ray Gwinn for the IBM PC and compatibles, and DECCOMM by Vince Perriello for the DEC Rainbow. FrontDoor A FidoNet mailer written by Joaquim Homrighausen. FSC001 In BinkleyTerm, an abbreviation that indicates that a mail session corresponding to the FSC-0001 standard is in use. FSC-0001 is a standards document written by the FidoNet Technical Standards Committee. GroupMail A method of sharing message areas devised by System Enhancement Associates, Inc., similar to EchoMail, except that responsibility for obtaining mail is placed on the receiving system, not the sending system as with EchoMail. Based on usage of update requests. Hold Area See "Outbound Area." Inbound Area Also known as the "NetFiles" area, this is a special sub- directory set aside for the acceptance of incoming mail or files from other network systems. Mail Packet A unit of mail as defined in the FidoNet Technical Standards Committee document FSC-0001. Mailer A program that acts as a FidoNet-compatible mail handler, using FidoNet protocol. Normally, a mailer answers the phone, accepts and/or sends mail, and possibly passes human callers on to a BBS. BinkleyTerm Version 2.30 - User's Guide - Page 58 msged An Opus/Fido compatible message reader/editor by Jim Nutt. Net A subset of a FidoNet compatible network, usually a collection of nodes within a metropolitan area. NetFiles Files received from other systems in the network; also a special sub-directory set aside for the reception of such files. NetMail Person-to-person mail sent through the network. Network As it applies to BinkleyTerm, a collection of nodes that are FidoNet compatible, such as the FidoNet network itself, or others such as EggNet, AlterNet, RBBS-Net, etc. Also, a division of a full network. See "Net" above. Node A FidoNet compatible system, represented by a node address, and listed in a nodelist. Nodelist A listing of FidoNet nodes. oMMM A packing program (packer) originally designed for Opus- CBCS, but now widely used with BinkleyTerm. Opus-CBCS "The Opus Computer Based Conversation System," a BBS designed by Wynn Wagner III. Uses ".MSG" message base (compatible with Fido BBS program). Contains built-in FidoNet compatible mailer. Outbound Area Also known as the "Hold Area," this is a special sub- directory set aside specifically for holding mail waiting to be sent to or picked-up by its destination. BinkleyTerm Version 2.30 - User's Guide - Page 59 Packer A program that processes mail entered on a system, and prepares it for sending by the mailer. Packet Within FidoNet, a message unit conforming to FSC-0001 specifications. With file transfer protocols, a block, or "piece" of the file transfer. Normally a pre-determined size in bytes. Point A point is an extension of a regular, fully qualified FidoNet node. The term is derived from the node address format, 1:104/36.2 for example, where 1 is a zone, 104 a net, 36 a node, and 2 is the point. Primarily, Points are intended to provide an method of participating in EchoMail conferences in an off-line state. The conferences are packed and held for the Point system by the Boss, a system which carries the desired conference(s) and is willing to route them to the Point. The Point system 'polls' the Boss for the conferences, which are unpacked and read off-line on the Point system. Responses are packed and sent to Boss in much the same manner as is done by regular FidoNet nodes. Generally, Points never interact with regular nodes, only with their Boss, since Point systems are not listed in the FidoNet nodelist. QuickBBS A BBS program designed by Adam Hudson, which uses configurable menuing and a database-style message base. Requires mail processing software designed specifically for its message format. Region A subset of a FidoNet compatible network, a collection of nodes within a broad geographical area. With regard to FidoNet addressing, a region is handled the same way as a network. With regard to operational infrastructure, this is a higher level than a net. Scan Usually associated with EchoMail processing, "scanning" is the process of taking new messages from a form usable by a BinkleyTerm Version 2.30 - User's Guide - Page 60 BBS program or message editor and preparing them for sending via the network by placing them in standard packet and/or compressed mail format. SEAdog A commercial FidoNet mailer by System Enhancement Associates, Inc. SEAlink A variant of Xmodem, a robust file transfer protocol featuring sliding windows, good error trapping and extended file information. Superior to Xmodem for use on difficult or satellite connected links. Sirius An Opus/Fido compatible message reader/editor by Bob Klahn. Sysop System operator; the person who operates a BBS, and/or the operator of a FidoNet node. TBBS A commercial BBS software package by eSoft, Inc. Telink An Xmodem variant, a file transfer protocol that is essentially Xmodem with a file information packet. Terminal Mode A BinkleyTerm mode within which the software may be used for manual, direct connections with remote modem-equipped computers. Toss Usually associated with EchoMail processing, "tossing" is the process of unpacking compressed mail into a form usable by a particular BBS program or message editor. TSYNC A signal sent to a FidoNet system from another FidoNet system attempting to pass mail traffic. TSYNC is essentially a "handshake" between the sending and receiving systems to synchronize the mail session. BinkleyTerm Version 2.30 - User's Guide - Page 61 Unattended Mode A BinkleyTerm mode within which FidoNet electronic mail may be sent or received. Undialable A term for nodes which will no longer be called automatically by the system until manually reset. The result of excessive unsuccessful connections with the remote system in an attempt to send mail. Unpacker A mail processing program that takes mail as received (compressed mail and/or packets) and places it into a form usable by a given type of BBS program or message editor. Update Request The ability and associated methods of requesting only a newer copy of a file located on one FidoNet system, if a newer copy exists, from another FidoNet system, using extended FidoNet protocol. VFOSSIL (Video FOSSIL Driver) A standard resident driver that allows a software program to access display hardware in a consistent manner regardless of hardware compatibility. This is an extension of the FOSSIL driver, and may not be supported by all FOSSIL drivers at this time. A VFOSSIL allows much faster access to the video display hardware than a FOSSIL driver alone would support. WaZOO An open architecture method of electronic mail transfer designed by Wynn Wagner, and originally used with Opus-CBCS. Various protocols can be used under WaZOO, including ZedZap, a slightly modified Zmodem, and DietIFNA, a SEAlink method. See 'YooHoo.' Xmodem One of the first of its type, a file transfer protocol designed by Ward Christensen. Although technologically behind other newer, more robust protocols, Xmodem is the most widely supported and implemented file transfer protocol in dial-up use. YooHoo A method of mail transfer session negotiation which determines if the remote system is capable of handling BinkleyTerm Version 2.30 - User's Guide - Page 62 WaZOO. FidoNet systems that do not support WaZOO will simply disregard the YooHoo; systems capable of supporting it will answer affirmatively, and a WaZOO session will be initiated. See 'WaZOO.' YooHoo is defined in the Fido Technical Standards Committee document FSC-0005. Zmodem A robust streaming file transfer protocol featuring advanced error recovery techniques, variable packet sizing, good error detection and extended file information. Extremely efficient, yet complex. Highly effective with difficult connections. Zone A large geographical sub-division in the network, the highest level of the accepted FidoNet addressing scheme. Broad areas such as continents are given zone designations. Also used to specify a particular alternate network. ZOOmail Simply archived mail packets, processed with the ZOO utility. Typically used to forward EchoMail messages due to the file compression inherent in the archiving process. Naming conventions correspond to a generally accepted method. See 'Mail Packet.'